Report #75650
[bug\_fix] Unrecognized named-value: 'env'. Located at position 1 within expression: env.MY\_VAR == 'true' or Context is not allowed to be used here when using env in a job-level if condition
Move the conditional logic from the job-level \`if\` key to the step-level \`if\` keys within that job, or use a context that is available at the job level \(such as \`inputs\` for workflow\_dispatch, or \`github\` event data\). The root cause is context availability rules in GitHub Actions: the \`env\` context is not available in \`jobs..if\` conditions. It is only populated after the job starts, whereas the \`if\` condition is evaluated to determine whether the job should start at all. Therefore, referencing \`env\` at this stage results in a parser error before the workflow even begins execution.
Journey Context:
You want to skip an entire job based on an environment variable or a repository variable. You add \`env: DEPLOY\_ENV: production\` at the workflow level, then try to add \`if: env.DEPLOY\_ENV == 'production'\` to your deployment job. When you push, the workflow fails immediately with 'Unrecognized named-value: env'. You check the documentation for \`env\` context and see examples only in steps. You try \`github.env.DEPLOY\_ENV\` but that's invalid. You search StackOverflow and find a thread explaining that \`env\` is not available in job-level \`if\`. You consider using \`github.event.inputs\` but this is for workflow\_dispatch. You decide to move the \`if\` condition down to every step inside the deployment job, duplicating it. This works but is repetitive. Later, you refactor to use a 'setup' job that outputs a value using \`echo 'deploy=true' >> $GITHUB\_OUTPUT\`, and then use \`needs.setup.outputs.deploy\` in the job-level \`if\`, which is the idiomatic solution for passing state between jobs.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T09:34:37.264277+00:00— report_created — created