4.4. Reflection Checkpoint

Key Takeaways

• Read a run outside-in: run header (trigger, actor, ref, SHA) → Set up job (image version, resolved actions, env) → step logs. Most "unexpected behavior" is a trigger or resolution mismatch, not a code bug.
• Re-runs replay the original commit and workflow version; they test flakiness, never fixes. Individual failed matrix jobs can be re-run alone.
• ACTIONS_STEP_DEBUG and ACTIONS_RUNNER_DEBUG are repository secrets/variables, not YAML keys. 403 "not accessible by integration" means token permissions; empty secrets mean scope or a fork PR; mass cancelled means fail-fast.
• Anchors expand and matrices multiply before execution — expand mentally before comparing config to behavior, and use matrix job names to correlate failures to axes.
• The UI's filters map onto REST parameters; log downloads redirect to signed URLs; download-artifact defaults to the current run and needs run-id/github-token/repository to cross runs or repositories.
• Binding time decides everything about reuse: starter = creation (drifts), reusable workflow = run time (job-level uses:), composite action = run time (step-level, inherits the caller's runner, no runs-on, no implicit secrets).
• Disable ≠ delete: disabling stops triggering reversibly and destroys nothing; deleting the file leaves run history intact. Scheduled workflows auto-disable after 60 days of repository inactivity.

Connecting Forward

Phase 5 crosses to the producer side of the ecosystem you've been consuming: authoring your own actions. The three action types, the action.yml contract, where immutable actions and immutable releases actually landed and what that means for pinning, and how you distribute and version something other teams will depend on.

Self-Check Questions

• Given only a run's header and its Set up job section, list three distinct classes of failure you could already rule in or out before reading a single step log.
• A composite action and a reusable workflow both "share logic across repositories." State the two capabilities each has that the other lacks, without repeating the phrase "steps vs jobs."
• Your organization wants scheduled compliance scans in 200 repositories, updated centrally, with per-repository schedule overrides. Which reuse mechanism carries the logic, which carries the schedule, and why can't one mechanism do both?