Closed jjgriff93 closed 4 months ago
Looking at the output, it seems that the action code passes --remote-env SUFFIX=
to the devcontainer
CLI.
My initial thought was that the action could detect this scenario and skip passing that env var to the CLI, but that would result in the env var not being set.
I ran a quick test of a GitHub action run that included the following step:
- name: env var test
env:
TEST_VAR:
run: |
printenv | sort
The output included TEST_VAR=
indicating that the environment variable was set as an empty string, so my inclination is to match this behaviour.
@chrmarti - what are your thoughts?
Current behaviour
We have a re-usable workflow that has an optional input called
suffix_override
like so:Then, in a
devcontainer/ci
step, we userunCmd
and pass several environment variables toenv
, including theinputs.suffix_override
:Because the suffix_override is optional, sometimes it's not set by the parent workflow. When that happens, because GitHub treats unset as empty strings, the
devcontainers/ci
step tries to set the env var; however it's empty, so we get an error:Note the
--remove-env SUFFIX=
which is the culprit.Expected behaviour
If an env is an empty string, follow the GitHub Actions behaviour and don't set it. To illustrate this is my current workaround:
@stuartleeks