Checkpoint Lab — Environment Variables, Configuration Variables, Outputs, and Data Passing

1. Checkpoint charter and safety boundary

2. Write predictions before creating the defect

1. Workflow-level APP_NAME will be visible in producer steps.
2. Producer Step 1 writes STAGE=assembled; Step 1 itself will not see the new value, but Steps 2/3 will.
3. Step 2 creates release_label through GITHUB_OUTPUT.
4. Step 3 confirms both same-job environment and step output.
5. In broken revision A, consumer will not receive CROSS_JOB_HINT written to producer GITHUB_ENV.
6. In repaired revision B, consumer receives the mapped release_label through needs.produce.outputs.release_label.

Also predict that the two jobs receive independent runner workspaces. A green producer does not imply the consumer has the producer's environment.

3. Revision A — deliberately broken transport

name: Chapter 05 checkpoint
on:
  workflow_dispatch:
    inputs:
      suffix:
        description: 'Synthetic release suffix'
        type: string
        required: true
        default: 'checkpoint'
permissions: {}

env:
  APP_NAME: chapter05-lab
  TRACK: ${{ vars.LAB_TRACK || 'fallback-track' }}

jobs:
  produce:
    runs-on: ubuntu-24.04
    steps:
      - name: Step 1 - establish same-job environment
        run: |
          echo 'STAGE=assembled' >> "$GITHUB_ENV"
          printf 'writer-sees-stage=%q\n' "${STAGE-}"

      - name: Step 2 - compute explicit step output
        id: meta
        env:
          SUFFIX: ${{ inputs.suffix }}
        run: |
          printf 'stage=%s track=%s\n' "$STAGE" "$TRACK"
          printf 'release_label=%s-%s\n' "$APP_NAME" "$SUFFIX" >> "$GITHUB_OUTPUT"

      - name: Step 3 - verify same-job data and create bad handoff
        env:
          LABEL: ${{ steps.meta.outputs.release_label }}
        run: |
          printf 'producer_label=%s stage=%s\n' "$LABEL" "$STAGE"
          echo "CROSS_JOB_HINT=$LABEL" >> "$GITHUB_ENV"
          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: Prove the misuse
        run: |
          printf 'consumer_hint=%q\n' "${CROSS_JOB_HINT-}"
          test -n "${CROSS_JOB_HINT-}"

4. Execute Revision A and preserve first-failure evidence

Dispatch with suffix=checkpoint. Record:

• Workflow/source SHA and run ID/attempt.
• Optional effective TRACK value (non-sensitive only).
• Step 1 log proving the writer step does not see newly written STAGE.
• Step 2/3 logs proving later same-job steps do see STAGE=assembled.
• Step 3 log proving the step output created the expected release label.
• Producer job conclusion = success.
• Consumer log showing empty CROSS_JOB_HINT and consumer conclusion = failure.

Do not edit the workflow until this packet is saved. The failed consumer is evidence, not noise.

5. Diagnose the causal layer

Event creation succeeded; YAML parsed; both jobs entered the graph; the producer runner executed successfully; permissions were irrelevant; no external action failed. The missing value appears only at the job boundary. That isolates the defect to data transport.

The producer already has the correct small value in steps.meta.outputs.release_label. The smallest repair is therefore to expose that value at the job interface and consume it through needs.

6. Revision B — replace ambient handoff with explicit job output

Change only the producer/consumer interface:

jobs:
  produce:
    runs-on: ubuntu-24.04
    outputs:
      release_label: ${{ steps.meta.outputs.release_label }}
    steps:
      # Keep the same three producer steps.
      # Remove CROSS_JOB_HINT as a supposed handoff.

  consume:
    needs: produce
    runs-on: ubuntu-24.04
    steps:
      - name: Consume explicit handoff
        env:
          LABEL: ${{ needs.produce.outputs.release_label }}
        run: |
          printf 'consumer_label=%s\n' "$LABEL"
          test "$LABEL" = 'chapter05-lab-checkpoint'

Keep the same trigger, suffix, runner label, permissions, optional repository variable, and synthetic values so the interface change is the only material difference.

7. Execute Revision B and compare causally

Record the new workflow SHA, run ID/attempt, producer/consumer conclusions, and output value. Verify the consumer succeeds. The difference between A and B should be explainable without invoking runner drift, token changes, or external service behavior.

8. Classify one file-shaped value

Add a thought experiment: producer generates evidence/report.json containing 5 MB of test evidence. Do not add its contents to the job output. Record that the correct production transport is an artifact/file mechanism, optionally paired with a small digest/path identifier output.

This checkpoint does not need an external artifact action to prove the design boundary; later chapters cover artifact mechanics in depth.

9. Required evidence packet

• Both workflow revisions with hashes.
• Prediction list completed before execution.
• Run IDs/attempts for A and B.
• Event name, source SHA, workflow SHA, runner OS/arch.
• Value ledger for APP_NAME, TRACK, STAGE, release_label, and the hypothetical report file.
• Producer Step 1/2/3 conclusions and bounded logs.
• Consumer failure evidence from Revision A.
• Exact job-output mapping and consumer success evidence from Revision B.
• Assumptions/limitations: no secrets, artifacts uploaded, packages, deployments, self-hosted runners, or cloud resources.

10. Verification checklist

• Exactly two jobs; producer has the three required progressive steps.
• permissions: {} remains unchanged.
• All values are synthetic/non-sensitive.
• GITHUB_ENV is used only as same-job state.
• GITHUB_OUTPUT creates the named step output.
• Revision B maps the output at job scope and consumes it through needs.
• Broken run remains preserved before repair.
• No whole-context dump or credential logging exists.
• 5 MB report is classified as artifact/file data, not an output.

11. Cleanup / rollback

1. Keep both runs until checkpoint review is complete.
2. Leave Revision B as the repaired state or revert the entire disposable branch after review.
3. Remove LAB_TRACK if it was created only for the lab.
4. Delete only learner-owned disposable repository resources after evidence retention needs are met.
5. No cloud, registry, environment, package, self-hosted runner, or credential cleanup is required.

12. What Chapter 05 adds to the production operating model

Chapter 05 adds the value-transport contract: every important value has a documented origin, sensitivity class, effective scope, precedence/owner, lifetime, transport mechanism, consumer, size/format expectation, and evidence trail. Same-job environment state stays same-job; cross-job control data uses explicit outputs; file-shaped evidence uses file/artifact transport; secrets remain outside ordinary configuration.

Chapter 06 can now focus on GITHUB_TOKEN, permissions, least privilege, and API access without conflating authorization with ordinary configuration/dataflow.

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.