Workflow level env does not work properly in all fields.

[timharris777]

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)

[dgflexera]

I'm just wondering if there is any update on this? :)

[timharris777]

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.

[leonardchu]

I'm new to GitHub, hence GitHub workflows. But this is the exactly the first issue I have with workflow. I'd image this is causing troubles for many of us.
Does anyone know the best way to attract attentions from GitHub on this?

[timharris777]

@leonardchu, give the first post a thumbs up. Github says that they monitor that. Other than that I'm not sure.

[pdecat]

Same issue with env in job strategy:

name: Python package

on: [push, pull_request]

env:
  target_python_version: 3.8

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      max-parallel: 5
      matrix:
        python-version: [3.7, "${{env.target_python_version}}"]

    steps:
    - uses: actions/checkout@v1
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v2
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install tox tox-gh-actions
    - name: Test with tox
      run: tox

.github/workflows/main.yml#L14The workflow is not valid. .github/workflows/main.yml (Line: 14, Col: 31): Unrecognized named-value: 'env'. Located at position 1 within expression: env.target_python_version

[adrienbernede]

Hello! I'm having the same issue in the following context:

step:
  - uses: ${{ env.org }}/repo/my_action@master

[roycdiscovery]

Same problem for me with if: ${{ github.ref != env.version }}

[rvernica]

It looks like instead of env a strategy.matrix variable with one value can be used in some cases.

[fabasoad]

Any workarounds on this? I can't use env on workflow level as well :(

[shlomif]

Any workarounds on this? I can't use env on workflow level as well :(

mine - for https://github.com/nektos/act :

diff --color -u -r .github/workflows/use-github-actions.yml .act-github/workflows/use-github-actions.yml
--- .github/workflows/use-github-actions.yml	2021-10-02 15:45:43.502705340 +0300
+++ .act-github/workflows/use-github-actions.yml	2021-10-02 15:45:43.516705231 +0300
@@ -2,6 +2,7 @@
     test-fc-solve:
         env:
             WHAT: ${{ matrix.env.WHAT }}
+        if: ${{ ! contains(env.ACT_SKIP, matrix.env.WHAT) }}
         runs-on: ubuntu-latest
         steps:
         -   uses: actions/checkout@v2
Only in .github/workflows: windows-x64.yml
Only in .github/workflows: windows-x86.yml

[oli414]

This is quite the dealbreaker for a dynamic workflow :-S I hope this can be resolved asap.

@shlomif looks promising, but I can't quite figure out what you're doing there. Could you provide a bit more context?

[shlomif]

@oli414 : I'm using an envvar to skip workflows, but only in the "act" configuration (where there isn't a problem) E.g:

act --workflows .act-github/workflows --rm --env-file <(echo "ACT_SKIP=,buildproc,")

[restjohn]

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.

[studioph]

Am also running into this issue trying to use env variables in matrix:

env:
  MIN_PYTHON_VER: 3.6.7
  LATEST_PYTHON_VER: 3.10.0

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        python-version:
          - ${{ env.MIN_PYTHON_VER }}
          - ${{ env.LATEST_PYTHON_VER }}

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...

[goneneren]

Here is context-availability for env:
https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability

[MSevey]

Any update? This still seems to be broken for me.

[dsdavis4]

Also looking for an update on this. Are there plans to fix?

[obinnaeye]

We're having this same issue now.

[mihaa1]

same

[mrjoboto]

+1, conditional runs-on is necessary for my workflow

[mihma]

Much needed feature

[kierans]

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.

[mcblair]

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.

[tbronsonCoveo]

We're also having issues with shared workflows because of the runs-on limits.
We cannot easily control memory usage of self-hosted runners using shared workflows.

[AllanOricil]

#2565 might be a different issue that is related to this one. Are expressions used in Jobs evaluated after the ones declared in Workflows ? If not, then it is another #2565 is another issue.
I want to use the result of a workflow expression in a Job using env variables. Why? Because there are many Jobs using the same expression in multiple places and I want to remove the duplications

[mxmnci]

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.

I'm facing the same issue. Why are we able to pass secrets into a reusable workflow but not env?

[Kaloszer]

How is this even an issue? Tagging resources is a perfect use case for this. It's been 3 years now, any news?

[github-actions]

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. 😃

[xor-freenet]

@TingluoHuang : @github-actions wrote:

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. 😃

1. This isn't a "feature request". This is a bug, and it was filed in the bugtracker as such. Thus please re-open it.

2. 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.

3. 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.

4. 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.