Support runtime GitHub event payload access - #366
Review submitted — approved
Review summary
Verdict
Approved PR #366 at ff50b4e6a967b3c767ac5730de405af95950376b with no inline findings.
Review: #366 (review)
Change reviewed
This change adds runtime access to whole, projected, and dynamically indexed github.event values without embedding the event in every immutable job plan.
The compiler still folds ordinary scalar event references when their values are available. If an expression must retain event access, the affected plan records the payload digest and a payload_artifact marker. Action inspection applies the same requirement to supported action input defaults, lifecycle conditions, composite metadata, Docker environments, and nested action invocations. Workflow-authored action references remain static and cannot be selected by event data.
When any plan needs the payload, bundle construction serializes one shared content-addressed artifact, checks the 25 MiB limit, and confirms that its digest matches the plan binding. Aggregate upload deduplicates that artifact across workflows, requires the importer job ID, and emits generated jobs that download artifacts from that exact producer.
At runtime, run-job downloads the event artifact before execution, reads it through the same 25 MiB bound, verifies its SHA-256 digest, rejects duplicate keys and non-object JSON, and installs the decoded object in the supported github context. The expression evaluator then supports event-rooted dynamic indexes and projections in workflow and action runtime surfaces. Plans continue to carry only the event identity, digest, and marker.
The documentation describes the artifact access and retention boundary and warns that the retained payload is unredacted. Token, secret, registry credential, OIDC, and internal admission data remain outside the snapshot.
Review coverage
I reviewed the complete 26-file PR diff against base 9c302ac15e3db2e9ad1d55ec7e906416a1d6de9f, including the integration with the normalized workflow program introduced on the updated base. I traced:
- compile-time reduction and runtime-retention detection in
internal/compiler/plan_builder.go - workflow and nested action metadata inspection in
internal/compiler/actions.go - shared artifact creation and cross-workflow consistency checks in
internal/compiler/bundle.goandinternal/cli/upload.go - exact importer-job binding in
internal/buildkite/pipeline.go,internal/cli/run_job.go, and the artifact transport adapter - plan schema, size, JSON-object, duplicate-key, and digest validation in
internal/plan/plan.go - dynamic and projected event evaluation in
internal/expression/ - runtime context hydration and action execution in
internal/runtime/action_execution.go - secret and GitHub token inventory after event reduction in
internal/program/authority.go - compatibility, CLI, and security documentation
I also checked all existing review threads. Earlier concerns about composite metadata coverage, action defaults, lifecycle index validation, condition root evaluation, and nested toJSON(github) detection are addressed in the current revision; all six threads are resolved.
Findings and evidence
No actionable correctness, security, or compatibility findings remained. In particular:
- jobs that only use reducible event scalars do not request the artifact
- one artifact serves all affected plans and workflows
- runtime downloads are constrained to the exact importer job rather than a retry-ambiguous step key
- event data cannot select action references or bypass the existing static secret and token authority scans
- absent, oversized, malformed, duplicate-keyed, or digest-mismatched payloads fail before workflow execution
- tests cover compiler retention decisions, action metadata surfaces, runtime hydration, plan validation, aggregate upload, and pipeline producer arguments
git diff --check passed. The visible product CI for Buildkite build 1880 passed, including the aggregate buildkite/buildkite-gha status, public-actions proof, all three shell-smoke jobs, and both Socket checks.
I could not run the Go test suite locally because this environment has neither Go nor mise. Direct Buildkite CLI access was also unavailable for the configured organization, so I verified build 1880 through the GitHub check rollup instead. No Linear issue was linked or discoverable from the PR; the description says this change supersedes GitHub PR #362.
Trigger source: comment.