Repository navigation
fix(ghcr): recognise KSail's form of the same root credential - #5681
Conversation
cluster update rewrites the root Flux Secret with KSail's username, password and auth fields, from the same Git/SOPS credential. The byte-exact check could never match after it, so the second credential pass of every deploy ran the full fenced transaction. Accept exactly that form, derived from the Git/SOPS credential; any other payload still takes the fenced path. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai review |
Action not completed
|
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 54 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Chef's kiss. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Evaluation at f425817. Exercised: the real script against the fake cluster: a root Secret in KSail's form of the same credential now takes the read-only path, with no controller restart. Before the change that same test failed. Six other payloads, including another token, another username, a disagreeing auth field and an extra registry, all end at Format check: KSail's own Not exercised: a production deploy. No live secret was read, so that the live payload is exactly this form is still inferred from the code. If it is not, the check keeps reporting Effect on production if it holds: after |
The merge queue removed this pull request at 17:46 UTC with Run 41331622603 failed in the deploy because the policy engine's webhook timed out while This run did not queue it again: its one merge attempt, on #5422, was refused (sample on monorepo#3902), and it stopped merging there. Pass 2 of #5650 is still unread until this lands. |
Queue re-entry checked at The source is unchanged, all reported checks pass, the exact-head Codex review is clean, and a fresh complete thread read is zero. No current claim or live local holder was found. Continuing with one normal head-pinned queue attempt. The recurring timeout remains open under #5692; pass-2 behavior and timing remain due on #5650 after merge. |
Removed from the queue again at about 21:06 UTC, for the same unrelated reason. Not re-queued. In merge-queue run 41347954355, This pull request does not cause it: the same message also removed #5687, which changes one allow-list file. Details are on #5692. Re-entry: wait until #5693 has deployed, then re-check the head ( |
Re-entered the queue at 22:06 UTC, head f425817, behind #5693 so its deploy follows the Kyverno fix. The earlier note said to wait for #5693 to deploy. Position in the queue gives the same order without the wait. The head is unchanged and Codex is clean at it. If #5693 is dropped again (see #5703), this PR no longer has the fix ahead of it: read the run before any further re-queue. |
Why
Every production deploy runs the full credential transaction twice, about 3 to 4 minutes each, and the platform queue waits on it. In all six deploys read today, the second run stopped at the root credential check. The cluster update had just rewritten that same credential in KSail's own format, and the check only accepts the Git format.
What
The read-only path now also accepts exactly KSail's format of the Git credential. A different token, username or extra entry, in either format, still runs the full transaction. The second run may still stop at a later check, because the update also re-renders node markers, so the next deploys are read to measure it before the issue closes.
Part of #5650