GitHub Actions Job Outputs: Pass Caption QA Status Without Sending Private Transcript Text

A Caption Test Needs to Pass a Result, Not the Recording

An oral-history website runs automated checks for subtitle timestamps, missing speaker labels and approved public versions. One GitHub Actions job performs validation; a later job decides whether the build may proceed to a release review. It is tempting to pass the entire transcript or a large JSON report between jobs as an output. GitHub’s job-output mechanism is designed for relatively small values, and output text can appear in workflow configuration, downstream environments or debugging. For interview recordings under restricted access, that is a poor data boundary. Instead, move only a narrow status and an opaque artifact identifier; leave the underlying content in an approved secured location with its own access controls.

Understand the Step-to-Job-to-Needs Chain

GitHub documents a three-stage data path. A step writes a named value to the GITHUB_OUTPUT environment file. The job maps that step value through jobs..outputs. A downstream job declares needs: validation and reads needs.validation.outputs.. These are different scopes: a step output is not automatically available to another job until the job-level mapping is defined. Use predictable names such as validation_state and report_id, and ensure every downstream expression references the correct dependency. The mechanism supplies data, not authorization. A string saying passed is only meaningful if the validator’s exit status and the supporting evidence are independently trustworthy.

Make the Output Contract Small and Explicit

Define a short allowlist: a state such as passed, failed or blocked; a version or checksum of the approved validation tool; and an opaque report reference, if needed. Put detailed findings in a restricted artifact or controlled storage system rather than into job outputs. Never emit names, direct interview quotes, consent notes or credentials. GitHub currently documents limits of 1 MB per job and 50 MB per workflow run for job outputs, but those ceilings are not target sizes. A three-field contract is easier to audit. Specify valid values and the behavior for missing or empty outputs so that a silent failure cannot be interpreted as an approval.

Preserve Validation Evidence Without Exposing It

Suppose the check finds a caption segment beyond the length of the video. The public job output can say failed and refer to an internal report ID. The report may contain timestamps and sanitized diagnostics; if it contains restricted words or personal information, store and share it only under the archive’s access policy. A build job should not print the full output map in ordinary logs. GitHub may redact outputs that appear to contain secrets, which means a consumer cannot assume every attempted value will arrive. Treat a skipped or missing output as a blocked handoff, not as an empty but successful review. Keep all tokens and release secrets out of the validation job where possible.

Distinguish Technical Pass From Editorial Consent

Caption quality has at least two gates. Automated checks can detect malformed timecodes, missing files and some structural problems. An editor must still verify transcript meaning, proper names, permissions, cultural sensitivities and accessibility conventions. Use a validation status for the technical stage and a separate human approval record for publication. If a job outputs passed but the consent paperwork is missing, the release remains blocked. Likewise, a reviewer marking approved does not repair broken subtitles. A visually clear diagram should show two different seals or gates rather than one green checkmark that blurs these responsibilities.

Compare Passed, Missing and Unsafe Handoffs

In a hypothetical successful run, the validator finishes with a passing status, writes a short output value, and a dependent review job receives that value. In a missing-output run, an expression yields no usable status, so the review gate stops and asks for investigation. In an unsafe handoff, a step attempts to send interview text as an output; even if the mechanics allow it, the design fails the data-minimization rule. These are teaching states, not observed GitHub run logs. Compare the exact output name, the upstream job result and the presence of a separate approved report reference. Do not infer a green release from a printed string alone.

Guard Against Untrusted Step Data

Outputs may originate from text processed by scripts or third-party actions. Do not interpolate uncontrolled content directly into shell commands in a later job. Validate allowed values and use appropriate environment-variable handling if downstream scripts need a string. Treat external pull requests as untrusted, keep workflow permissions minimal, and avoid granting publish credentials to a caption-lint job. Where an uploaded artifact is involved, verify its identity, revision and access boundary rather than trusting a contributor-supplied file name. A downstream job should refuse to proceed if the output value is not one of the documented statuses or if the upstream dependency did not finish successfully.

Run a Synthetic Workflow Before Enabling the Gate

Use fictional text and a tiny test transcript in a staging repository. First, produce a valid output through the documented environment-file syntax and confirm it is available through needs. Then deliberately misspell an output name, output an empty string, fail the upstream job and test a value outside the allowlist. Check whether the downstream task correctly remains blocked. Inspect runner logs and artifacts for accidental copying of sensitive content. The security team can review the permission model and secret handling. This article has not executed the workflow or accessed any private interview; these are test cases to run before production use.

Hand Off Only the Evidence Needed for Release

A trustworthy release handoff names the source commit SHA, the validator revision, the technical result, an approved report reference and the editor who granted publication permission. Store the full transcript in the controlled archive, not in ephemeral CI output variables. Keep manual approval separate from automated success and make missing evidence fail closed. When a team changes the validator or workflow syntax, rerun the staging cases. The resulting system communicates enough information for a downstream job to decide whether it may request release approval, without making confidential oral-history text available to every job, log viewer or collaborator.

Related guides

• GitHub Actions GITHUB_OUTPUT: Pass Caption QA Verdicts Between Steps Without Treating Them as Approval
• GitHub Actions GITHUB_JOB: Label Caption QA Artifacts Without Mixing Up Workflow Runs
• GitHub Actions Job Summaries: Show Translation QA Failures Without Publishing Draft Copy

How We Research

For this guide, we reviewed the official product documentation on November 8, 2026: GitHub passing information between jobs, GitHub workflow syntax for outputs, GitHub Actions contexts reference. We checked the named setting or feature against its published behavior, mapped the documented constraints to the specific hypothetical scenario, and reviewed whether the topic duplicated titles in the LabFin WordPress inventory or prior B0267–B0275 ZIPs. No authenticated vendor service was run; we did not perform a benchmark, observe real customer data, verify third-party rights or claim operational outcomes. All illustrated records and comparisons are teaching examples. Confirm product documentation and security requirements again before implementing a workflow in a real organization.

Frequently Asked Questions