User Story
As a release engineer, I want merge-queue E2E, Release Dev E2E, and Linux packaging to consume one immutable artifact set for a commit SHA, so that the artifacts tested before merge are the artifacts later packaged and released.
Problem Statement
CI currently produces overlapping run-scoped artifacts. Merge-queue E2E receives prebuilt CLI and gateway binaries, while Release Dev E2E can rebuild workspace binaries and packaging has separate producers. There is no durable, digest-verified artifact manifest that consumers can resolve by source SHA.
Impact / Why This Matters
This divergence can hide failures that depend on the binary delivery path, including the rootless Podman E2E discrepancy. Rebuilding increases CI time and makes it harder to establish which exact artifact was tested and packaged.
Proposed Design
For trusted merge-group and main flows, CI resolves one immutable Linux artifact manifest by source SHA. A miss builds and publishes the required artifacts; a hit verifies source metadata and digests before reuse. E2E and Linux packaging consume resolved artifacts without source-build fallback. The manifest is published only after its complete artifact set is available.
Acceptance Criteria
Alternatives Considered
- Continue using workflow-run-scoped GitHub Actions artifacts: cannot reliably share across merge-queue and post-merge workflows.
- Rebuild in every consumer: preserves current behavior but does not prove tested and released binaries match.
- Use mutable tags alone: does not provide an immutable, auditable artifact identity.
Agent Investigation
The existing Docker build workflow already creates Linux binary artifacts and SHA-tagged images. Branch E2E downloads run-scoped CLI/gateway artifacts, whereas Release Dev invokes the shared E2E workflow without artifact inputs. Release Dev packaging has separate binary producers.
User Story
As a release engineer, I want merge-queue E2E, Release Dev E2E, and Linux packaging to consume one immutable artifact set for a commit SHA, so that the artifacts tested before merge are the artifacts later packaged and released.
Problem Statement
CI currently produces overlapping run-scoped artifacts. Merge-queue E2E receives prebuilt CLI and gateway binaries, while Release Dev E2E can rebuild workspace binaries and packaging has separate producers. There is no durable, digest-verified artifact manifest that consumers can resolve by source SHA.
Impact / Why This Matters
This divergence can hide failures that depend on the binary delivery path, including the rootless Podman E2E discrepancy. Rebuilding increases CI time and makes it harder to establish which exact artifact was tested and packaged.
Proposed Design
For trusted merge-group and main flows, CI resolves one immutable Linux artifact manifest by source SHA. A miss builds and publishes the required artifacts; a hit verifies source metadata and digests before reuse. E2E and Linux packaging consume resolved artifacts without source-build fallback. The manifest is published only after its complete artifact set is available.
Acceptance Criteria
Alternatives Considered
Agent Investigation
The existing Docker build workflow already creates Linux binary artifacts and SHA-tagged images. Branch E2E downloads run-scoped CLI/gateway artifacts, whereas Release Dev invokes the shared E2E workflow without artifact inputs. Release Dev packaging has separate binary producers.