CI build provenance
Attach a source commit to the exact image produced by your pipeline.
Self-hosted alpha.18 accepts a per-service provenance map in plan and deployment requests. Your pipeline can keep building images while Hakopod records the commit, repository and run behind each submitted image.
Record the build’s source commit#
Each service entry must contain the exact digest-pinned image reference from its specification, the full source commit ID, provider and repository. A run URL and branch are optional. Get the commit from the checkout actually used to build the image, especially when a pipeline uses another repository or a remote build context.
Include provenance in both the reviewed plan and deployment. It is recorded atomically with the immutable release and included in the idempotency hash. Changing metadata while reusing a request key returns a conflict.
What CI provenance verifies#
External records are marked ci_reported. They contain metadata submitted by an authenticated pipeline. Hakopod does not independently verify that the image was built from that source, verify registry signatures or fetch the workflow URL. If submitted records disagree, Hakopod marks the provenance as ambiguous instead of choosing a commit.
A record proves which metadata was accepted. It does not prove that every pod is ready or that a bug is fixed. Check deployment success, runtime image IDs and the application behavior separately. Unknown older images are not silently backfilled.
Use the complete versioned CI example, alongside the deployment guide.