Repository navigation
Publish prod manifests through an immutable staging reference so latest never names unsigned bytes #2849
Description
🤖 Generated by the Agentic Engineer
Evidence
ghcr.io/devantler-tech/platform/manifests:latest is moved by ksail workload push, and signing does
not begin until three steps later. Measured on main (2026-07-28), step positions in
.github/actions/deploy-prod/action.yml:
| # | Step |
|---|---|
| 9 | 📦 Push manifests to GHCR — latest now points at the new bytes |
| 12 | 🖋️ Sign OCI manifest with cosign |
| 14 | 🪪 Attest SBOM |
| 15 | 🪪 Attest build provenance |
| 18 | 🔁 Trigger Flux reconciliation |
There is no staging reference: the mutable tag is the publication target, so the artifact is reachable
under the name production tracks for the whole span between steps 9 and 15.
Audience and problem
The cluster's root Flux source polls that tag on a 1-minute interval and delivers the entire platform —
every controller, tenant binding and policy. Today spec.verify on that source is null, so the window is
latent. It becomes load-bearing the moment root verification is switched on (#2627's other child): Flux
can resolve bytes whose signature or attestations do not exist yet.
Hypothesis
Publishing to an immutable reference, completing the evidence against it, and only then repointing
latest closes the window without changing what production ultimately runs.
First step is measurement, not a guess
Open question to answer first: whether ksail workload push can target a reference other than
latest. If it can, this is a deploy-path change. If it cannot, the capability belongs in KSail and this
issue depends on that work. Nothing else here should be designed before that is settled.
Acceptance criteria
latestis only repointed once the signature and both attestations exist for that exact digest.- A failed push, sign, or attest leaves the previously verified artifact active under
latest. - The DR rebuild path publishes through the same transaction (it writes the same tag).
- A static test pins the transaction, in the shape of
scripts/validate-publication-order(test(ci): pin the prod publication ordering so evidence precedes release #2848).
Rough size: M — the transaction itself is small; the KSail capability question is what decides whether
this is one repo or two.
Part of #2627
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Start date
Target date
Effort
Projects
- Status
Activity
coderabbitai commentedon Jul 28, 2026
🔗 Related PRs
#2319 - feat(security): cosign-verify the infrastructure Flux OCI artifact [merged]
#2625 - fix(deploy): synchronize production GHCR pull auth [merged]
#2633 - fix(deploy): verify incoming image on Talos nodes [merged]
#2635 - fix(deploy): reboot stale nodes so containerd adopts refreshed GHCR auth [merged]
#2793 - feat(cilium): activate homogeneous device selection [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!