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

nive-copia commented 1 year ago

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 commented 1 year ago

I'm having the same issue

nicole0707 commented 1 year ago

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

rajrupdasofficial commented 1 year ago

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

nive-copia commented 1 year ago

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 commented 1 year ago

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

lucasmellos commented 1 year ago

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 commented 1 year ago

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

srinadhbh commented 1 year ago

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 commented 1 year ago

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

hurricup commented 1 year ago

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 commented 1 year ago

I'm having the same issue 😐

iBasit commented 1 year ago

+1

alexl-shopware commented 1 year ago

+1. Get this fixed github, cmon.

whsalazar commented 1 year ago

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

hurricup commented 1 year ago

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

harrisrobin commented 1 year ago

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

whsalazar commented 1 year ago

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 commented 1 year ago

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

rijnhard commented 1 year ago

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

kschaer commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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