Fix GitHub Actions Unrecognized env Errors

DEV Community

GitHub Actions unrecognized named-value: env and the context table

GitHub Actions unrecognized named-value: env means the expression sits in a workflow key whose list of allowed contexts does not include env, most often runs-on, jobs..if, a job name, or the with: of a reusable workflow call, all of which are evaluated before a runner exists. The fix is to move the value, not reword the expression: use a vars variable, a job output read through needs, or a step-level if, which does accept env. The rows people trip on. A job-level condition takes four contexts and four status functions, and neither env nor secrets is among them. What this error means The workflow is invalid and nothing runs. The message names the context in quotes, gives its position inside the expression, and prints the expression back to you, which makes the whole thing read like a typo even though the spelling is right. Two details give the real shape away. The same name works elsewhere in the same file, usually one key higher or one key lower, and the name that is rejected is almost always env or secrets. Both are contexts that exist, are documented, and are simply not permitted in the key where you used them. A long annotation with several of these separated by commas means the parser found every one of them in a single pass, so fixing the first line will not shorten the list. ```Invalid workflow file, quoted from actions/runner#480 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

Common causes

env used in a key that is evaluated before the runner exists

The largest group by far: runs-on, jobs.<job_id>.if, jobs.<job_id>.name, a job-level concurrency, or the with: of a called workflow. All of them are decided while the job is still being planned, and the environment belongs to a runner that has not been picked yet.

secrets used in a condition

A job-level or step-level if does not accept the secrets context, by design rather than by omission. The documented replacement is to copy the secret into a job environment variable and test that, which also gives you a reliable way to ask whether a secret is set at all.

matrix or strategy in a workflow-level key

The workflow-level keys, run-name, the top-level env and a workflow-level concurrency, are read before any job exists, so neither matrix nor strategy is on their lists. Inside a job the parser does not check whether a strategy is declared: matrix.os in the runs-on of a job without a matrix is accepted and resolves to an empty value. In our experience the rejected version arrives when a matrix value is promoted to a workflow-level env to share it between jobs.

steps read from a job-level key

The steps context belongs to the job that is running and holds only steps "that have an id specified and have already run". A job-level if, a runs-on or a with: in a caller cannot see it, because at that point no step has run. Job outputs and the needs context are the way to move a value up a level.

How to fix it

Look up the key, not the expression

1. Take the workflow key from the line and column in the message, not the context name.
2. Find that key in the context availability table and read the list of contexts it accepts.
3. If the name you used is missing, move the value rather than rewriting the expression.

Use a repository variable where you wanted a workflow env

The vars context is available in nearly every key in the table, including runs-on, a job-level if and a caller with:. A value that is configuration rather than a per-run computation belongs there, and moving it removes the whole class of problem rather than working around one instance.

```.github/workflows/ci.yml (illustrative)
jobs:
build:
runs-on: ${{ vars.RUNNER_LABEL }}
steps:
- run: echo building
Compute it in a job and read it through needs When the value really is computed at run t...

Powered by Readybot.io