Suggestion: Allow passing environment variables separated by line breaks for easier input
The documentation says the following on passing environment variables:
env: host=api.dev.local,port=4222When passing the environment variables this way, unfortunately due to GitHub Actions syntax, the variables should be listed in a single line, which can be hard to read.
What a lot of other actions tend to do is allow passing multiple items on multiple lines, making use of YAML's linebreak preserving syntax:
env: |
host=API.dev.local
port=4222
In the action code, you can then just do something akin to env.includes("\n") ? env.split("\n") : env.split(",") for improved ergonomics with very little effort.
@Radiergummi
The quote from the documentation is an excerpt only and the full section Env reads as follows. This provides an alternative for having one line per environment variable:
Env
Specify the env argument with env parameter
name: Cypress tests
on: push
jobs:
cypress-run:
runs-on: ubuntu-24.04
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Cypress run with env
uses: cypress-io/github-action@v6
with:
env: host=api.dev.local,port=4222
When passing the environment variables this way, unfortunately due to GitHub Actions syntax, the variables should be listed in a single line, which can be hard to read. As an alternative, you can use the step's env block where every variable can be set on its own line. In this case, you should prefix every variable with CYPRESS_ because such variables are loaded by Cypress automatically. The above code example is equivalent to:
name: Cypress tests
on: push
jobs:
cypress-run:
runs-on: ubuntu-24.04
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Cypress run with env
uses: cypress-io/github-action@v6
env:
CYPRESS_host: api.dev.local
CYPRESS_port: 4222
For more examples, see the workflows below, using environment variables for recording.
A flexible alternative, as suggested in this enhancement request, would be beneficial and these types of enhancements in the past years have relied on community contributions, so if you are confident to implement this proposal you may consider submitting a PR.
Note that behind the scenes the action uses both the Cypress Module API and, as an alternative, Cypress CLI, so any changes need to cover both scenarios and would need to have tests added as well as code changes to the action.