Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workflow level env does not work properly in all fields. #480

Closed
timharris777 opened this issue May 15, 2020 · 47 comments
Closed

Workflow level env does not work properly in all fields. #480

timharris777 opened this issue May 15, 2020 · 47 comments

Comments

@timharris777
Copy link

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)

@timharris777 timharris777 added the bug Something isn't working label May 15, 2020
@TingluoHuang TingluoHuang added service Service Bug Bug fix scope to the pipelines service and launch app and removed bug Something isn't working service labels Jun 8, 2020
@dgflexera
Copy link

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

@timharris777
Copy link
Author

timharris777 commented Jan 26, 2021

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

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
Copy link
Author

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

@pdecat
Copy link

pdecat commented Mar 20, 2021

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

pdecat added a commit to fbradyirl/openwrt-luci-rpc that referenced this issue Mar 21, 2021
Publish to pypi only once in github actions

Notes:

* Github Actions does not support env in job strategy: actions/runner#480 (comment)

* Trigger the workflow on push or pull request, but only for the master branch, see https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-using-multiple-events-with-activity-types-or-configuration
@adrienbernede
Copy link

adrienbernede commented Apr 9, 2021

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

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

nicoulaj added a commit to nicoulaj/rainbow that referenced this issue Apr 18, 2021
@roycdiscovery
Copy link

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

@rvernica
Copy link

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

glutanimate added a commit to glutanimate/pytest-anki that referenced this issue Aug 31, 2021
Sadly it looks like the env context can only be used inside steps:

actions/runner#480
@fabasoad
Copy link

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

@shlomif
Copy link

shlomif commented Oct 10, 2021

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

oli414 commented Oct 24, 2021

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

shlomif commented Oct 25, 2021

@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
Copy link

restjohn commented Nov 10, 2021

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

studioph commented Nov 15, 2021

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

bauerj pushed a commit to bauerj/paperless_app that referenced this issue Sep 5, 2022
* Make Flutter Build workflow reusable

* provide artifact name via input variable (with default value)

* Automatically add build artifacts to github release

* workaround for actions/runner#480
ajschmidt8 added a commit to rapidsai/rmm that referenced this issue Sep 8, 2022
apparently `env` isn't supported in `with:` statements.
see actions/runner#480
@goneneren
Copy link

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

@MSevey
Copy link

MSevey commented Nov 15, 2022

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

@dsdavis4
Copy link

dsdavis4 commented Dec 9, 2022

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

@obinnaeye
Copy link

We're having this same issue now.

@mihaa1
Copy link

mihaa1 commented Dec 28, 2022

same

@mrjoboto
Copy link

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

@mihma
Copy link

mihma commented Jan 31, 2023

Much needed feature

@kierans
Copy link

kierans commented Feb 7, 2023

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.

latipun7 added a commit to latipun7/charasay that referenced this issue Mar 1, 2023
latipun7 added a commit to latipun7/charasay that referenced this issue Mar 1, 2023
@mcblair
Copy link

mcblair commented Mar 15, 2023

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

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

AllanOricil commented Apr 25, 2023

#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
Copy link

mxmnci commented May 24, 2023

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

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

@ruvceskistefan ruvceskistefan added actions-feature and removed Actions Feature Feature requires both runner, pipelines service and launch changes labels Nov 16, 2023
Copy link
Contributor

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests