runner: Workflow level `env` does not work properly in all fields.
Describe the bug
When using workflow level environment variables they do not work when I use them to substitute for jobs.build.name
or jobs.build.runs-on
. See workflow file below for example:
name: Testing workflow leve env vars
on:
push:
branches:
- develop
env:
aws_account: cfaittoolsnp
environment: dev
jobs:
build:
name: Deploy|${{ env.aws_account }}
runs-on: ${{ env.aws_account }}
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Init
run: |
echo ${{ env.aws_account }}
To Reproduce
Steps to reproduce the behavior:
1.- Run the workflow file above to receive the following error:
The workflow is not valid. .github/workflows/dev.yml (Line: 15, Col: 11): Unrecognized named-value: 'env'. Located at position 1 within expression: env.aws_account,.github/workflows/dev.yml (Line: 16, Col: 14): Unrecognized named-value: 'env'. Located at position 1 within expression: env.aws_account
Expected behavior
The expected behavior is that using the workflow file above the build.name
would be Deploy|cfaittoolsnp
and the build.runs-on
would be cfaittoolsnp
.
Runner Version and Platform
Running latest version of linux self-hosted runner.
OS of the machine running the runner? linux (ubuntu 18.04)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 263
- Comments: 47 (1 by maintainers)
Commits related to this issue
- Publish to pypi only once in github actions (#47) Publish to pypi only once in github actions Notes: * Github Actions does not support env in job strategy: https://github.com/actions/runner/iss... — committed to fbradyirl/openwrt-luci-rpc by pdecat 3 years ago
- workaround https://github.com/actions/runner/issues/480 — committed to nicoulaj/rainbow by nicoulaj 3 years ago
- work around https://github.com/actions/runner/issues/480 — committed to awslabs/aws-crt-python by graebm 3 years ago
- Switch back to hard-coding latest Anki config Sadly it looks like the env context can only be used inside steps: https://github.com/actions/runner/issues/480 — committed to glutanimate/pytest-anki by glutanimate 3 years ago
- ci: replaced environment variables by its content Replaced environment variables by its content due to a bug (https://github.com/actions/runner/issues/480) — committed to teneko-net-tools/Teronis.Nullable by teneko 3 years ago
- Revert "GitHub Actions: Try if using env vars to specify build matrix is possible" This reverts commit d67c491c4ea4aec0c19b095db2da4b805379df0a. It seems that using environment variables here is jus... — committed to xor-freenet/plugin-WebOfTrust-DO-NOT-USE-1 by xor-freenet 2 years ago
- :bug: workflow-level env가 동작하지 않는 이슈를 해결하라 https://github.com/actions/runner/issues/480 이유는 알 수 없으나, 동작 안함. — committed to dshare-inc/.github by decorus-kazuma 2 years ago
- workaround: use workaround for github runner bug ref: https://github.com/actions/runner/issues/480 — committed to nbrugger-tgm/java-spring-template by nbrugger-tgm 2 years ago
- Github Action - Trying workaround to actions issue #480 https://github.com/actions/runner/issues/480 — committed to coutcout/bouchon by coutcout 2 years ago
- Github Action - Trying workaround to actions issue #480 https://github.com/actions/runner/issues/480 — committed to coutcout/bouchon by coutcout 2 years ago
- Feature/cicd (#2) * Create docker-image.yml * Delete docker-image.yml * Initialisation de l'action "build-docker". On liste les fichiers qui sont checkout * Ajout du build gradle * Sup... — committed to coutcout/bouchon by coutcout 2 years ago
- ci: Debug GitHub Actions env var & try set-output workaround for actions/runner#480 — committed to LyraPhase/sprout-wrap by trinitronx 2 years ago
- ci: Test string compare without actions/runner#480 set-output workaround — committed to LyraPhase/sprout-wrap by trinitronx 2 years ago
- replaced environment variables by its content Trying workaround to actions issue https://github.com/actions/runner/issues/480 — committed to zhongfly/mpv-winbuild by zhongfly 2 years ago
- Use dedicated job to setup parameters instead of using env https://github.com/actions/runner/issues/480 — committed to cropsinsilico/yggdrasil by langmm 2 years ago
- Use dedicated job to setup parameters instead of using env https://github.com/actions/runner/issues/480 — committed to cropsinsilico/yggdrasil by langmm 2 years ago
- Not possible to resolve ${{ env.xxx }} in "with:" https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability https://github.com/actions/runner/issues/480#issuecomment-10212... — committed to ihostage/playframework by mkurz 2 years ago
- feat/metrics: remove env.rust_min Details: https://github.com/actions/runner/issues/480#issuecomment-968397824 — committed to hit-box/hitbox by topenkoff 2 years ago
- feat/metrics: turn off parallel tests; remove env.rust_min 1. metrics in tests use shared collector and after running each test, you need to create new state for the objectivity of the tests 2. Detai... — committed to hit-box/hitbox by topenkoff 2 years ago
- [CI] Fix invalid release version received from env https://github.com/actions/runner/issues/480 — committed to vividus-framework/vividus-test-app by uarlouski 2 years ago
This is also an issue with reusable workflow. For example:
Does not work.
@restjohn wrote:
Thanks for your input 😃
It may be true that that is how the implementation is implemented and intended currently (or not true, who knows?)
But: The sole purpose of an implementation of software is to serve the users needs, it has no purpose of its own.
Therefore, if it cannot serve the needs of the users, it has to change.
It should not be the other way around, the users should not be asked to change their needs to follow the needs of the implementation 😃
Same issue with
env
in jobstrategy
:Same problem for me with
if: ${{ github.ref != env.version }}
Am also running into this issue trying to use env variables in matrix:
The fact that one has to hard-code values for things like language and os versions in a separate place, rather than being able to DRY and define them once and reuse them, is really disappointing.
Also disappointing that this is the 7th most liked issue yet has not received a single response from Github in over a year…
@tjcorr +1 for not working with reusable workflow. I’m having the same problem.
Any news on this? Really annoying on reusable workflows 😦
@TingluoHuang : @github-actions wrote:
This isn’t a “feature request”. This is a bug, and it was filed in the bugtracker as such. Thus please re-open it.
Human lifetime is a finite resource. We will all die, and we will never get back time which was taken from us.
~43 people have spent their lifetime to comment on this annoying issue, 259 have spent their time to search the bugtracker for this issue in order to push the “like” button.
So you are wasting the lifetime of around 200-300 people by asking them to re-file this issue in the “Community Support forum”.
This is not a nice thing to do, please stop doing it by re-opening the issue.
Still: Thanks for your time as well 😃 Let’s keep things civil and thus keep this issue open.
Given this issue has annoyed hundreds of people for over 3 years now, and probably many more who didn’t spend the effort to comment here, how about you just fix it? There are plenty of suggestions on how to fix it in the discussion.
Please don’t hide behind the “github-actions” bot when commenting here, it is super annoying to have to dig through dozens and dozens of comments to figure out who is reponsible in order to highlight them. I just highlighted the first person to tag this issue now, @TingluoHuang, but I cannot know if this is the person who closed it, which is suboptimal.
Maybe
env
is not the right mechanism for some of these use cases. What I’d like to see at least is for the Actions YAML parser to support aliases and anchors in order to create reusable elements in the workflow file.I don’t get it, is the documentation wrong or it does not explains much that we can’t use env in reusables workflow actions? Please update the github actions documentation regarding envs limitations.
My use case is to call a reusable workflow, which requires some secrets as input and you can only use
secrets
in the job level, so I had to move theuses
to the job level, but my reusable workflow itself also requires some inputs, which is definited in my workflow env… so now I can not pass those envs to my reusable workflow because of this limitation…I took what @umarcor suggested, and I think I’ve got a nice workaround which allows env vars to be shared in the way we’re all looking for:
Essentially we use
jq
to parse out the env vars from theparams
step, which inherit the initialenv
values, and saves this as an output you can use in other jobs. FYI it includes all the other env var junk, I’m sure you can filter it out if needs be.This solution seems to work for our usecase.
Thank you for your interest in the runner application and taking the time to provide your valuable feedback. We kindly ask you to redirect this feedback to the GitHub Community Support Forum which our team actively monitors and would be a better place to start a discussion for new feature requests in GitHub Actions. For more information on this policy please read our contribution guidelines. 😃
@paulhutchings, in pyTooling/Actions we use a
Params
job to generate an object of “global parameters” which we can then use in any job. See:fromJson(needs.Params.outputs.params)
is certainly ugly, but it is usable in places whereenv.params
fails. Moreover, since we generate theparams
dynamically, we can declare them imperatively (say Python) and not just declaratively; we can also filter them and/or produce warnings.That is not a solution to this issue, but at least a usable workaround.
Find a more complex variant of this approach in https://github.com/actions/runner/issues/1182#issuecomment-982696462, where a YAML file with anchors is used for generating the job matrix dynamically.
Unfortunately, no-- env can still not be used. However, I have found that I can use either of the following:
runs-on: ${{ needs.init.outputs.tag }}
-> You would need to export the tag for the runner as an output in a previous step.runs-on: ${{ github.event.inputs.tag }}
-> You would need to provide an input for the runner tag via worfklow_dispatch.Confirm, we’d like to be able to define an environment variable that can be used in
runs-on
Honestly it is pretty unacceptable that the
env
context is only available when the entirety of a workflows logic is in the same file.Our use case is far from uncommon: use the
env
context within inputs for a re-usable workflow.The concept to realize, I think, is that the intent of environment variables is for them to be available in the context that a job step is executing, not in the context of DEFINING a job, which is basically the context of the GitHub Actions platform itself. If you need dynamically computed values for job definition elements, you need to compute them in a step as outputs, as some have commented above, then reference them from subsequent steps. Now, there might be potential for a less cumbersome solution than having to use outputs and
needs
references, such as user-defined variables and functions that can augment the job definition context, butenv
is certainly not the correct place for that.mine - for https://github.com/nektos/act :
Hello! I’m having the same issue in the following context:
For some of the use cases outlined in this issue (eg: using a variable in a job name), it looks like Variables is what you’re after.
Here is context-availability for env: https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability
@restjohn, did you see #1182 and actions/starter-workflows#245 ?
Any workarounds on this? I can’t use
env
on workflow level as well 😦I’m just wondering if there is any update on this? 😃