Repository navigation
chore(security): approve a newer canonical manifest-publisher revision so the shared configuration can update #4713
Description
Activity
🤖 Generated by the Agentic Engineer
Both halves are merged; one observation is left.
- fix(github-config): accept the next reviewed publisher revision beside the current one #4767 merged and deployed at 02:06 UTC on 2026-10-12. Read back from production: the
github-configsource is Ready and accepts the shared publishing workflow at the old revision (2fa40427) and the new one (63c59062). - chore(deps): bump devantler-tech/.github/.github/workflows/publish-manifests.yaml from 7.2.10 to 7.9.0 .github#562 (the pin bump to that new revision) merged at 02:13 UTC, after Codex re-reviewed it clean.
Still to observe: that merge did not cut a new
.githubversion (latest is still v7.9.3), so nothing has been published with the new signer yet. On the next.githubversion tag I read thegithub-configsource back on production; Ready on the new version closes this issue. If it is rejected instead, the fallback is unchanged: the old revision is still accepted, so reverting the pin restores publishing.- fix(github-config): accept the next reviewed publisher revision beside the current one #4767 merged and deployed at 02:06 UTC on 2026-10-12. Read back from production: the
- added a commit that references this issue
on Oct 12, 2026 🤖 Generated by the Agentic Engineer
Observed on production (10:09 UTC, 2026-10-12): the new signer works. Closing.
.githubv7.9.4 was released at 09:17 UTC, the first version published since the pin moved.- The
github-configsource on production is Ready on7.9.4(digestsha256:9f1b19de…), with its current settings observed. - The updater's own record (chore(security): regenerate the approved publish-workflow revisions #4791) resolves that release's signing identity to the shared publishing workflow at the new revision
63c59062, so the release was accepted through the newly approved revision, not the old one. - All five Flux kustomizations are Ready on one revision.
Nothing further is owed here.
Evidence
The shared automation repository publishes its configuration release through its own manifest-publishing workflow, pinned to the release v7.2.10. Dependabot proposes moving that pin to v7.9.0 (devantler-tech/.github#562), and the update fails its publishing-contract check on purpose: the cluster accepts configuration releases from the canonical publisher only when they are signed at the one reviewed revision this repository approves, which is still the v7.2.10 commit (
k8s/bases/apps/github-config/oci-repository.yaml). Merging the update first would publish releases the cluster rejects, with nothing failing in the publishing repository.The earlier tracking issue (#4502) covered accepting the canonical publisher at all and is closed. Nothing tracks moving the approved canonical revision forward, and the generated approvals list (
scripts/publish-workflow-approved-revisions.tsv) does not add it.Problem
The shared automation repository cannot adopt eight minor releases of its own publishing workflow, and its update PR stays open and red, until this repository approves a newer canonical revision.
Hypothesis
Approving the newer reviewed revision alongside the current one, deploying that, and only then moving the pin lets the publisher update with no window in which the cluster rejects a release.
Acceptance criteria
Depends on
A working production deploy path (the recovery in #4709 / #4710).