OPENFAAS_URL env variable does not override gateway set in stack.yaml

[welteki]

Expected Behaviour

When OPENFAAS_URL is set, it should override the gateway value from stack.yaml, allowing users to target a different gateway without modifying the stack file or passing --gateway on every command.

The expected priority order should be:

1. --gateway flag
2. OPENFAAS_URL environment variable
3. gateway from stack.yaml
4. Default gateway (http://127.0.0.1:8080)

Current Behaviour

The OPENFAAS_URL environment variable is ignored when a non-default gateway is set in stack.yaml. The gateway from the YAML file takes precedence over the environment variable.

This does not happen when the gateway in stack.yaml is set to the default URL http://127.0.0.1:8080.

Why do you need this?

When deploying to different environments (dev, staging, prod) using the same stack.yaml, it should be possible to override the gateway using the OPENFAAS_URL environment variable without editing the YAML file or remembering to pass --gateway every time.

Who is this for?

OpenFaaS users deploying functions across multiple environments.

Are you a GitHub Sponsor (Yes/No?)

• Yes
• No

List All Possible Solutions and Workarounds

1. Fix priority order in getGatewayURL: Change commands/priority.go so that environmentURL is checked before yamlURL.
2. Workaround: Use the --gateway flag explicitly on every command: faas-cli deploy -f stack.yaml --gateway=https://gw.example.com
3. Workaround: Remove the gateway from stack.yaml and rely on OPENFAAS_URL or --gateway exclusively.

Which Solution Do You Recommend?

Solution 1 - Fix the priority order in getGatewayURL so environment variable takes precedence over the YAML value, matching user expectations and common CLI conventions where environment variables override config files.

Steps to Reproduce (for bugs)

1. Create a stack.yaml with a gateway set:

   faas-cli new --lang python3-http import-csv --gateway https://gw.example.com
   

2. Set the OPENFAAS_URL environment variable to override the gateway:

   export OPENFAAS_URL=https://gw.staging.example.com
   

3. Deploy using the stack file:

   faas-cli deploy -f stack.yaml
   

4. Observe that the CLI tries to use the gateway from stack.yaml instead of OPENFAAS_URL:

   Deploying: import-csv.
   
   Is OpenFaaS deployed? Do you need to specify the --gateway flag?
   Put "https://gw.example.com/system/functions": dial tcp: lookup gw.example.com on 127.0.0.53:53: no such host
   
   Function 'import-csv' failed to deploy with status code: 50
   

5. Deploying with --gateway flag works as expected:

   faas-cli deploy -f stack.yaml --gateway=https://gw.staging.example.com
   

Context

Discovered while working on a CI pipeline that deploys functions to different gateways.

Your Environment

• FaaS-CLI version:

CLI:
 commit:  bb85f62465ba515042164cd30ba578c24ced092c
 version: 0.18.7

• Docker version:

Client: Docker Engine - Community
 Version:           29.3.0
Server: Docker Engine - Community
 Engine:
  Version:          29.3.0

• Are you using Docker Swarm (FaaS-swarm) or Kubernetes (FaaS-netes)? Kubernetes

• Operating System and version: Linux (Ubuntu 24.04 LTS)

• Link to your project or a code example to reproduce issue: N/A