The env Context

~9 min · env, context, scoping

Level 0Apprentice

0 XP0/101 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

Three layers of env

Environment variables in workflows can come from three layers, with predictable precedence:

Step env — defined under a step's env:. Highest priority for that step.
Job env — defined under a job's env:. Visible to all steps in that job.
Workflow env — defined at the top level. Visible everywhere.

If two layers define the same name, the more specific layer wins (step > job > workflow).

Reading env from expressions

Two access methods, with a subtle difference:

Inside a shell run: $VAR (bash) — uses the actual process environment at execution time.
In an expression: ${{ env.VAR }} — read at parse time, before the step runs. Some context is not yet available; see below.

Context precedence in the GITHUB_ENV file

Steps can write to $GITHUB_ENV to add an env var that's visible in subsequent steps. This is how you compute a value in step 2 and use it in step 5.

Code

Three env layers + GITHUB_ENV pass-through·yaml

name: env-demo
on: { workflow_dispatch: {} }

env:
  REGION: us-east-1            # workflow level

jobs:
  one:
    runs-on: ubuntu-latest
    env:
      DEBUG: 'true'             # job level
    steps:
      - run: echo "$REGION $DEBUG"
      - env:
          DEBUG: 'false'        # step level (wins)
        run: echo "$REGION $DEBUG"

      - name: Compute version
        id: version
        run: |
          v=$(cat VERSION)
          echo "VERSION=$v" >> $GITHUB_ENV

      - name: Use computed env
        run: echo "Building $VERSION for $REGION"

External links

GitHub — env context reference

Exercise

Take a workflow that hardcodes a value in three places. Hoist it to a workflow-level env:. Verify a single edit propagates everywhere.