What's changed: New GH-200 Chapter 1 (triggers & events = push/pull_request/schedule/workflow_dispatch/repository_dispatch/workflow_call with inputs/secrets; workflow structure = jobs/steps/needs/if, env/$GITHUB_ENV, service containers, strategy.matrix, contexts/${{ }}, YAML anchors; execution mgmt = artifacts/$GITHUB_OUTPUT/cache/$GITHUB_STEP_SUMMARY/badges/environment protections/retention REST API)
1.3Managing Execution and Outputs — Cache, Artifacts, Outputs, and Job Summaries
Understand how to pass data between jobs/steps (artifacts, $GITHUB_OUTPUT, $GITHUB_ENV, reusable-workflow outputs), dependency caching, Markdown job summaries via $GITHUB_STEP_SUMMARY, status badges, environment protections, and managing retention of logs/artifacts/runs via REST APIs.
As Section 2 showed, jobs run in isolation, so you need to pass results explicitly. GH-200 uses three paths by purpose—artifacts for files/build outputs, $GITHUB_OUTPUT (and $GITHUB_ENV for env vars) for short values between steps/jobs, and outputs that a reusable workflow returns to its caller. You then combine caching to speed builds, job summaries to present results clearly, and status badges to surface state.
1.3.1Artifacts — passing files/build outputs
To keep files—build outputs, test reports, logs—for later jobs or post-run download, upload with actions/upload-artifact and retrieve with actions/download-artifact. Artifacts are stored against the run and auto-deleted after the default retention period (tunable via repo/org settings or retention-days at upload). This is the typical way to pass files between jobs: a later job (after needs) downloads and uses them.
1.3.2Passing values — $GITHUB_OUTPUT and job outputs
To pass short values (version numbers, decisions), create a step output with echo "name=value" >> "$GITHUB_OUTPUT" and read it within the same job via steps.<id>.outputs.<name>. To pass to another job, assign step outputs to the job’s outputs: map and have the dependent job read needs.<job>.outputs.<name>. Artifacts are "for files," while this is "for small values"—keep that distinction to choose correctly. Reusable workflows likewise define outputs to return results to the caller.
| What to pass | Mechanism | How to read |
|---|---|---|
| Files/build outputs | Artifacts (upload/download) | download-artifact (after needs) |
| Short value (same job) | $GITHUB_OUTPUT | steps.<id>.outputs.<name> |
| Short value (to another job) | Job outputs | needs.<job>.outputs.<name> |
| Env var (later steps) | $GITHUB_ENV | env.<NAME> / $NAME |
1.3.3Speeding up with caching
Re-downloading dependencies (npm, pip, Maven) wastes time and cost. actions/cache saves/restores a dependency directory keyed by, e.g., a lockfile hash, speeding up later jobs. Even without an exact match, restore-keys can restore an older partial-match cache. Note that cache (reproducible intermediates) and artifacts (outputs you want to keep) serve different purposes—cache is purely for speed and should hold things you can regenerate if lost.
1.3.4Job summaries and status badges
To present results clearly, append Markdown to $GITHUB_STEP_SUMMARY—tables of test results, coverage, and links render as a rich job summary on the run page. Surface repo-wide state with a status badge (an SVG badge in the README) that shows the latest result (pass/fail) for a given branch/event at a glance.
1.3.5Environment protections and retention
An environment (e.g., a deploy target) can carry protection rules—approval gating via required reviewers, a wait timer, branch restrictions on which branches may deploy, and environment-scoped secrets/variables. This enforces "production deploys only after approval." Operationally, set retention for logs, artifacts, and workflow runs at the repo/org level to auto-delete stale data. These retention settings and artifact fetch/delete operations are also available via the REST API, so you can automate cleanup and compliance.
Common: (1) pass files between jobs = artifacts (upload/download-artifact). (2) short values = $GITHUB_OUTPUT → steps/needs.<job>.outputs. (3) env var to later steps = $GITHUB_ENV. (4) speed up deps = actions/cache (key + restore-keys). (5) rich run summary = $GITHUB_STEP_SUMMARY (Markdown). (6) gate production deploys = environment required reviewers / wait timer / branch restrictions. (7) Retention and artifacts are manageable via the REST API.
Watch out: (1) Artifacts (outputs to keep) and cache (regenerable speed-up data) differ—test reports are artifacts; node_modules is cache. (2) Don’t confuse $GITHUB_OUTPUT (values) with upload-artifact (files). (3) Environment protections and branch protection rules are separate layers. (4) Artifacts past retention are deleted—use external storage for long-term archives. (5) Legacy commands like set-output are deprecated—use $GITHUB_OUTPUT.
1.3.6Section summary
- Files via artifacts (upload/download-artifact); short values via $GITHUB_OUTPUT → steps/needs.<job>.outputs; env vars via $GITHUB_ENV
- actions/cache (key + restore-keys) speeds up deps; cache ≠ artifacts
- $GITHUB_STEP_SUMMARY for Markdown job summaries; status badge in README
- Environment protections (required reviewers/wait/branch) gate deploys; retention and artifacts via REST API
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A build job produces a binary that a later deploy job needs. What is the standard way to pass files between jobs?
Q2. You computed a version string in one job and want another job to read it. Which is most appropriate?
Q3. Builds are slow because npm dependencies are re-downloaded every time. Which mechanism saves/restores reproducible deps to speed them up?
Q4. You must enforce that production deploys run only after approval by specific people. Where do you configure this?
Q5. You want a table of test results and coverage shown clearly on the run page. Where do you write it?
Q6. You want to auto-delete old artifacts/logs and automate cleanup. What can manage their retention and artifacts?