"Unrecognized named-value: 'env'. Located at position 1 within expression" when used in reusable workflow jobs

[nive-copia]

Describe the bug
Usage of env in workflow that uses reusable workflow generates "Unrecognized named-value: 'env'. Located at position 1 within expression"

To Reproduce
Use the following yml:

name: Test Workflow

on:
  push:

env:
  SOMETHING: 1000

  test:
    name: call workflow
    uses: ./.github/workflows/callee.yml
    secrets: inherit
    with:
      run_url: "{run_url}"
      message: ${{ env.SOMETHING }}

Expected behavior
env.SOMETHING is usable and can be passed into reusable workflow

Actual behavior

The workflow is not valid. .github/workflows/create-branch.yml (Line: #, Col: ##): Unrecognized named-value: 'env'. Located at position 1 within expression: env.SOMETHING

Runner Version and Platform

Version of your runner?

OS of the machine running the runner?
ubuntu-latest

What's not working?

[GrayJack]

I'm having the same issue

[nicole0707]

I have the same issue, there is workaround to use $GITHUB_OUTPUT instead.

[rajrupdasofficial]

Having the same issue . When it's going to fix?
any work around of it?

[nive-copia]

Hi GHA folks: Any update on providing this capability? Some of us are using workarounds, including the one suggested by @nicole0707. But, having this feature will make the intent very clear and clean.

[ghost]

hello! if i can help u. or something need to do.say step b step

[lucasmellos]

workaround is to use as a secret in the main workflows and then you'll be able to parse it to env in the reusable workflow like

env:
   SECRET: ${{secrets.MY_SECRET}}

[hoancs]

I'm having the same issue. Have we got any update?

[srinadhbh]

workaround is to use as a secret in the main workflows and then you'll be able to parse it to env in the reusable workflow like

env:
   SECRET: ${{secrets.MY_SECRET}}

In my case, git is considering subscription id as a secret. I am trying to print NSG/ASG id and git is omitting the output.

[hurricup]

Trying to use this approach to workaround #520 and bummer...

[hurricup]

It is also unavailable in called workflow. I tried to move check into there and got:

b5676355294c9b6943a4a68c5 (Line: 14, Col: 9): Unrecognized named-value: 'env'. Located at position 1 within expression: env.COVERALLS_REPO_TOKEN Camelcade/Perl5-IDEA/.github/workflows/_coverage.yml@d08cee137234bd0b5676355294c9b6943a4a68c5 (Line: 14, Col: 9): Unexpected symbol: '${{'. Located at position 1 within expression: ${{ env.COVERALLS_REPO_TOKEN }}
    secrets: inherit

Called workflow is:

# re-usable workflow to merge and process coverage
name: Coverage

on:
  workflow_call:

env:
  COVERALLS_REPO_TOKEN: ${{ secrets.COVERALLS_REPO_TOKEN }}

jobs:
  analyze:
    name: Analysis
    runs-on: ubuntu-latest
    if: ${{ env.COVERALLS_REPO_TOKEN }}
....

[carrill1]

I'm having the same issue 😐

[iBasit]

+1

[alexl-shopware]

+1. Get this fixed github, cmon.

[whsalazar]

The env context is not available from jobs.<job_id>.with.<with_id>. See https://docs.github.com/en/enterprise-cloud@latest/actions/learn-github-actions/contexts#context-availability

[hurricup]

@whsalazar the question is what the reason behind this? And if there is no real reason, would be nice to have it.

[harrisrobin]

I guess I wasted 30 mins of my life and ended up here like the rest of us

[whsalazar]

You can't use the env context outside steps, as described in the docs:

You can use the env context in the value of any key in a step except for the id and uses keys. Feel free to submit feedback and feature request at https://github.com/orgs/community/discussions/categories/actions?discussions_q=is%3Aopen+env+jobs+category%3AActions

[guanyingjie]

I have the same issue, hope github action can pass the env variable in the furture

[rijnhard]

Nasty workaround: https://stackoverflow.com/a/74217028/834280

[kschaer]

Same problem here. I have several reusable workflows that should receive the same with inputs - it's a shame I cannot simply set up the environment variables in the parent (caller) workflow and pass to the reusable (child) workflows.

[miguelangelgil]

The solution is to pass the environment variables as the output of a job:

name: Test Workflow

on:
  push:

env:
  SOMETHING: 1000

jobs:
 get-env-vars:
    name: Get Environment vars
    runs-on: some-runner
    outputs:
      SOMETHING: ${{ env.SOMETHING }}
    steps:
      - run: echo "null"

  test:
    name: call workflow
    needs: [get-env-vars]
    if: ${{ always() }}
    uses: ./.github/workflows/callee.yml
    secrets: inherit
    with:
      run_url: "{run_url}"
      message: ${{  needs.get-env.outputs.SOMETHING }}

[ffineis]

Hey this got me really close - at least now i can reference names of env vars I need in with, but this approach won't work if the original env variable is a secret since GH doesn't export outputs that are secrets.

Warning: Skip output 'MY_SECRET' since it may contain secret.

[miguelangelgil]

@ffineis To pass secrets use secrets instead with. In the above case i use secrets: inherit that take the secrets that you define in yours reusable workflow if they are accessible from the current workflow.

[ffineis]

@miguelangelgil yes thanks secrets: inherit was the trick to expose secrets in the reusable workflow - thx! Wish I had seen this after 3 hours of smashing head in.

[joshjohanning]

You can use ${{ vars.MY_VAR }} stored in the repository instead of env when referencing in reusable workflows. Not perfect, but it works

[sajati]

2023 and still have the same issue

[anajuliabit]

please github devs do something 😩

[ulidtko]

@anajuliabit I'm mostly sure that exactly 0 of GH devs are subscribed to every issue and are reading every comment. You'd have to summon their attention via explicit pings.

For example, ping @ericsciple @TingluoHuang

[ericsciple]

The env context is not supported under jobs.<job_id>.with.<with_id>

Refer https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#context-availability

[ericsciple]

To elaborate a bit more, env is for process environment variables. Also, secrets can be mapped into env, so if secrets isn't allowed, then env isn't allowed either.

Similarly, the secrets context is generally only allowed within a job. It is not allowed within fields that are used by our server to manage the workflow orchestration.

[ericsciple]

Skimming the replies regarding use cases...

One solution might be to check-in a script which sets up your job environment variables. https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable. For scenarios involving run-context or workflow dispatch inputs, $GITHUB_EVENT_PATH might also help.

Not perfect, but might work for many scenarios.

[ericsciple]

Also note, reusable workflows are sort of a security boundary. That is why env values don't flow to reusable workflows. Otherwise callers could influence the jobs in ways unintended by the reusable workflow author. E.g. consider https://github.blog/changelog/2022-03-21-github-actions-restrict-self-hosted-runner-groups-to-specific-workflows/

[ulidtko]

Hi @ericsciple thanks for responding 🙏

I know it's tough to unbundle the assortment of various issues that are being conflated into one. Perhaps you can think of error message improvements that'd send people to corresponding docs explaining that certain usage isn't supported, neither will be? That'd be super helpful to reduce confusion, as apparently there's a lot of difficulty in locating the authoritative docs.

For example, I'm coming from a (prematurely closed) issue #1189 which reports the same error — but without reusable workflows, secrets, and under jobs.<job_id>.env (not in jobs.<job_id>.with.<with_id>).

I.e. this does not work, throws the error:

jobs:
  acme-bundle:
    runs-on: ubuntu-20.04
    needs: build
    env:
      # if triggered from a branch containing /, use "wip", otherwise tag name
      version: ${{ contains(github.ref_name, '/') && 'wip' || github.ref_name }}
      fullfilename: acme-${{ env.version }}.${{ github.sha }}.bundle
    steps:
      [...]
      - name: Pack
        run: tar -czf $fullfilename --format posix -C DIST .
      - name: Upload
        run: aws s3 cp $fullfilename s3://$BUCKET/ACME/$version/$fullfilename

#-- NOTE: the workflow author wants both values as env-vars, to be used in shell steps.
#-- NOTE: the second var is defined using the first var ${{ env.version }}

# ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
# The workflow is not valid. .github/workflows/release.yml (Line: 190, Col: 21):
# Unrecognized named-value: 'env'. Located at position 1 within expression: env.version

Can this be helped with somehow?

[ericsciple]

+1 thanks @ulidtko - good feedback. I will forward along internally.

[bnhmn]

This didn't work back in late 2021 when reusable workflows were introduced and it still doesn't work three years later in 2024. See you in 3 years.

[KornevNikita]

Another +1. Hopefully by the 1001st comment we'll get this working.

[ulidtko]

Ping @ericsciple, any update you could give publically?..

[ab-smith]

Another +1 indeed; I understand that env is probably not ideal but we should have a proper alternative pattern in this case for reusability.

[esaporski]

Soon we can wish this issue a Happy Birthday! 🎂

[Armadillidiid]

It seems like I'm early to the party. Just encountered this issue

[magusd]

well, looks like it's hopeless waiting for a solution, will try one of the workarounds

[roeezolantz]

Any chance? 😢

[hugtalbot]

Wow, we just faced this issue and discovered it's a real issue, not yet solved 😲
Any solution would be appreciated

[dyahnov]

Same here today, wtf?

[munyaradzi-hobbstech]

This needs to be fixed guys

[hantastic3]

This needs to be fixed

[esaporski]

Forget about it guys, GitHub Actions is abandonware.

[rik-howard]

Please fix this