Environment Variables, Configuration Variables, Outputs, and Data Passing: Guided Hands-On Workflow

1. Disposable lab and preflight

Create a throwaway repository such as gha-dataflow-lab. The mandatory lab needs only GitHub-hosted ubuntu-24.04 and shell commands. Do not add secrets, PATs, cloud credentials, releases, packages, environments, or self-hosted runners.

2. Build the workflow progressively

name: Chapter 05 dataflow lab
on:
  workflow_dispatch:
    inputs:
      suffix:
        description: 'Synthetic suffix'
        type: string
        required: true
        default: 'alpha'
permissions: {}

env:
  APP_NAME: dataflow-lab
  SCOPE_MARKER: workflow

jobs:
  produce:
    runs-on: ubuntu-24.04
    env:
      SCOPE_MARKER: job
      CONFIG_CHANNEL: ${{ vars.LAB_CHANNEL || 'not-configured' }}
    outputs:
      release_label: ${{ steps.compute.outputs.release_label }}
      line_count: ${{ steps.compute.outputs.line_count }}
    steps:
      - name: Step 1 - inspect scope and write same-job env
        env:
          SCOPE_MARKER: step
        run: |
          printf 'app=%s scope=%s config=%s\n' "$APP_NAME" "$SCOPE_MARKER" "$CONFIG_CHANNEL"
          echo 'DERIVED_STAGE=verified' >> "$GITHUB_ENV"
          printf 'producer-step-derived=%q\n' "${DERIVED_STAGE-}"

      - name: Step 2 - consume env and publish outputs
        id: compute
        env:
          SUFFIX: ${{ inputs.suffix }}
        run: |
          printf 'derived_stage=%s\n' "$DERIVED_STAGE"
          printf 'release_label=%s-%s\n' "$APP_NAME" "$SUFFIX" >> "$GITHUB_OUTPUT"
          echo 'line_count=3' >> "$GITHUB_OUTPUT"
          {
            echo 'NOTE<> "$GITHUB_ENV"

      - name: Step 3 - verify same-job values
        env:
          LABEL: ${{ steps.compute.outputs.release_label }}
          COUNT: ${{ steps.compute.outputs.line_count }}
        run: |
          printf 'label=%s count=%s stage=%s\n' "$LABEL" "$COUNT" "$DERIVED_STAGE"
          printf 'note=%s\n' "$NOTE"
          printf 'run=%s attempt=%s sha=%s\n' "$GITHUB_RUN_ID" "$GITHUB_RUN_ATTEMPT" "$GITHUB_SHA"

  consume:
    needs: produce
    runs-on: ubuntu-24.04
    steps:
      - name: Consume explicit cross-job interface
        env:
          LABEL: ${{ needs.produce.outputs.release_label }}
          COUNT: ${{ needs.produce.outputs.line_count }}
        run: |
          printf 'received_label=%s received_count=%s\n' "$LABEL" "$COUNT"
          printf 'consumer local DERIVED_STAGE=%q\n' "${DERIVED_STAGE-}"

The last line is deliberate evidence: DERIVED_STAGE is empty in the consumer because it came from GITHUB_ENV in the producer job. Only the mapped job outputs cross the boundary.

3. Predict before dispatch

4. Dispatch and capture run identity

Dispatch with suffix=alpha. Record the run ID, attempt, event name, source SHA, workflow SHA, job IDs/names, and runner OS. Preserve these values alongside the exact workflow revision before editing anything.

If you configured LAB_CHANNEL, verify its value appears only as ordinary unmasked configuration. Do not place any sensitive test value in it.

5. Prove environment precedence and same-job propagation

Use the logs to reconcile each prediction. The evidence should show scope=step in Step 1, an empty immediate DERIVED_STAGE, then derived_stage=verified in Step 2 and Step 3. This is more useful than memorizing “GITHUB_ENV works”: you have proven exactly when the runner injects the value.

6. Prove the explicit step → job → downstream-job chain

The producer publishes release_label and line_count through GITHUB_OUTPUT. The job maps those names in outputs:. The consumer can then read only what the job interface exposes through needs.produce.outputs.*.

This is intentionally different from reaching into another job's filesystem or process environment. The dependency edge and output names are visible in code review.

7. Multiline environment values: delimiter safety matters

The NOTE example uses a fixed delimiter only because the payload is fully synthetic and known not to contain that delimiter on a line by itself. For arbitrary external data, current GitHub guidance warns not to rely on delimiter framing if a collision is possible; write arbitrary content to a file instead.

That distinction also protects you from turning an untrusted payload into runner control syntax. Keep external text as data, quote it, and prefer files for opaque content.

8. Output or artifact? Apply a transport test

Imagine Step 2 also creates report.json containing 8 MB of structured evidence. Do not encode it into GITHUB_OUTPUT. The correct design is a file/artifact path because it is larger, file-shaped, and may need retention/download. Keep only a small identifier or digest as an output if downstream control flow needs one.

9. Challenge: add one new value without hidden coupling

Add a synthetic build_kind value. Decide first whether it is static workflow configuration, centrally managed configuration, a runtime step output, or a file. Then implement only the smallest channel that matches your classification and state which scope owns it.

A correct answer is not one specific keyword; it is a defensible value contract with producer, consumer, lifetime, and evidence.

10. Verification and cleanup

• Confirm no secret or credential was configured or logged.
• Confirm permissions: {} remained unchanged.
• Confirm consumer receives only named job outputs, not producer ambient state.
• Record the workflow revision and run ID/attempt before cleanup.
• Remove the optional LAB_CHANNEL repository variable if you created it solely for the disposable lab.
• Delete only learner-owned disposable resources after retaining evidence as long as needed.

Knowledge check

Official references and version notes

• Variables — current distinction between workflow env, configuration variables, default variables, and secrets.
• Variables reference — current default variables, naming rules, precedence, configuration-variable limits, and context guidance.
• Store information in variables — current examples for workflow/job/step environment variables, configuration variables, contexts, and cross-step/job data flow.
• Workflow commands for GitHub Actions — current environment files including GITHUB_ENV, GITHUB_OUTPUT, multiline syntax, and restrictions.
• Passing information between jobs — current job-output mapping and needs.<job>.outputs consumption.
• Workflow syntax for GitHub Actions — current env, job outputs, needs, output size limits, and workflow syntax.
• Store and share data with workflow artifacts — current artifact model for files that must outlive a step/job filesystem or are inappropriate for small outputs.
• GitHub Actions changelog: set-output update — why new workflow code should use environment files rather than the deprecated stdout set-output command.