How does one GitHub Actions job pass a computed value to a later job?

## Why a chain and not a variable Jobs in a GitHub Actions workflow run on separate runners with separate filesystems and separate processes. Nothing a job computes is visible anywhere else unless the job *publishes* it. The publishing mechanism is deliberately narrow — it moves strings, not state — and it has three hops. ## Hop 1: step output A step writes to the file whose path is in the `GITHUB_OUTPUT` environment variable: ``` - id: meta run: echo "version=$(cat VERSION)" >> "$GITHUB_OUTPUT" ``` Two requirements. The step needs an `id:` — without one there is no name to read it back by. And the write must **append** (`>>`), because the runner may already have content in that file from earlier writes in the same step. Other steps in the same job now read `${{ steps.meta.outputs.version }}`. This is job-local: the `steps` context does not cross a job boundary. For a multi-line value, use the delimiter form rather than trying to echo newlines: ``` { echo "notes<<EOF" cat CHANGELOG.md echo "EOF" } >> "$GITHUB_OUTPUT" ``` An action invoked with `uses:` sets its outputs the same way internally, so `steps.<id>.outputs.<name>` works identically for action steps — the action's `action.yml` documents which names exist. ## Hop 2: job output A job publishes selected step outputs through its own `outputs:` map: ``` jobs: build: runs-on: ubuntu-latest outputs: version: ${{ steps.meta.outputs.version }} steps: - id: meta run: echo "version=1.4.2" >> "$GITHUB_OUTPUT" ``` The keys under `outputs:` are the *public* names — they need not match the step output names. The expressions are evaluated at the end of the job, which means a job that never reached that step publishes an empty string rather than failing. ## Hop 3: the consumer The consuming job must declare the dependency; the `needs` context only contains jobs the job actually needs: ``` deploy: needs: [build] runs-on: ubuntu-latest steps: - run: ./deploy.sh "${{ needs.build.outputs.version }}" ``` Omitting `needs: [build]` does not produce a helpful error — the expression simply evaluates to an empty string, and the script gets an empty argument. That silent-empty failure mode is the single most common bug with this feature, and the debugging move is to echo the value first. ## The traps worth naming in an interview **Secrets are redacted.** If a value the job tries to publish matches a secret, GitHub removes it from the job output. Passing a credential from job to job this way does not work and is not supposed to; the consumer should read the secret itself. **Matrix jobs collide.** Every job generated by a matrix shares one job id, so all of them write the same output names and the last to finish wins, with no defined ordering. If you need per-variant values, write them to artifacts with variant-specific names, or aggregate in a single downstream job that downloads all of them. **Outputs are strings.** There are no numbers, booleans, or objects. `if: needs.build.outputs.publish == 'true'` compares strings — the quoting matters. To move structured data, publish JSON as a string and parse it with `fromJSON` on the other side, which is also how a downstream matrix can be built from an upstream job's computation. **Outputs are not files.** A jar, a coverage report, or a container tarball goes through `actions/upload-artifact` in the producer and `actions/download-artifact` in the consumer. Outputs carry only the *name* of such a thing. ## Contrast with $GITHUB_ENV Beginners reach for `$GITHUB_ENV` when they mean `$GITHUB_OUTPUT`. Appending to `$GITHUB_ENV` sets an environment variable for **subsequent steps of the same job** — useful, but it stops at the job boundary and cannot be republished as a job output directly. `$GITHUB_OUTPUT` is the one that participates in the three-hop chain. A third file, `$GITHUB_STEP_SUMMARY`, is for human-readable Markdown shown on the run page and carries no data at all.