runner: Workflow level `env` does not work properly in all fields.

This is also an issue with reusable workflow. For example:

env:
  DOTNET_VERSION: 5.0.x    

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  call-workflow-passing-data:
      uses: ....reusable.yml@main
      with:
          dotnetversion: ${{ env.DOTNET_VERSION }}`

Does not work.

@restjohn wrote:

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. […] 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, but env is certainly not the correct place for that.

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

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

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…

@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:

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.

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 the uses 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:

env:
   FOO: foo
   BAR: bar
jobs:
    params:
        name: Make environment variables available to the rest of the workflow
        runs-on: ubuntu-latest
        outputs:
            params: ${{ steps.env-vars.outputs.params }}
        steps:
            -   name: install jq
                run: pip install jq
            -   id: env-vars
                name: Output environment variables
                run: echo "::set-output name=params::$(echo $(jq -n 'env'))"

    setup:
        needs: [ params ]
        name: Setup
        runs-on: ubuntu-latest
        steps:

            -   name: Use Foo
                run: echo ${{ fromJson(needs.params.outputs.params).FOO }}
            
            -   name: Use Bar
                run: echo ${{ fromJson(needs.params.outputs.params).BAR }}

Essentially we use jq to parse out the env vars from the params step, which inherit the initial env 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:

• Params.yml
• ExamplePipeline.yml

    needs:
      - Params
    with:
      artifact: ${{ fromJson(needs.Params.outputs.params).artifacts.coverage }}

fromJson(needs.Params.outputs.params) is certainly ugly, but it is usable in places where env.params fails. Moreover, since we generate the params 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, but env is certainly not the correct place for that.

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

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

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

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

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.

@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? 😃