Can workflow-level 'env:' values reference other context variables like 'github.ref'?
Select an answer to reveal the explanation.
Short Explanation
Yep, you can use ${{ github.ref }} right up at the top of the workflow. Workflow-level env: gets the github, secrets, inputs and vars contexts, which covers most of what you'd want there. It's the job-and-runner stuff, like matrix or steps, that has to wait until you're inside a job or step.
Full Explanation
GitHub Actions publishes a context availability table that lists which contexts each workflow key may use in expressions. For the top-level env key, the allowed contexts are github, secrets, inputs and vars, and no special functions are available. An entry such as BRANCH: ${{ github.ref }} in workflow-level env is therefore evaluated and resolves to the triggering ref, and the variable is inherited by every job and step. Saying workflow-level env is evaluated before any context exists is wrong, because the github context is already populated from the triggering event when the workflow starts. Saying any context can be used goes too far: needs, strategy, matrix, job, runner and steps describe a specific job or its progress, and none of them exist at workflow scope. Limiting it to the github context alone ignores the secrets, inputs and vars contexts that the table also permits. The static versus dynamic distinction is not a concept the table uses; availability is decided per context, not by whether a value changes between runs. Job-level env adds needs, strategy and matrix, and step-level env adds job, runner, env and steps plus the hashFiles function. Exam caveat: an expression that references an unavailable context at workflow scope causes a workflow validation error rather than a literal string. Operational check: print the variable in an early step and confirm it shows the expected ref for a push and for a pull request.