fix(apps): pin tenant OCI manifest tags - #2737
Merged
devantler merged 11 commits intoAug 18, 2026
Merged
Conversation
Contributor
Author
|
Contributor
Author
|
@cursor review |
Contributor
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_13fcb2f8-74cf-44f3-8e7a-036bcfbb9d9f) |
devantler
commented
Aug 9, 2026
devantler
left a comment
devantler
left a comment
Contributor
Author
There was a problem hiding this comment.
🤖 Generated by the Agentic Engineer
Static exact-head review of 34665f7d3c28803b186fa34df53e0c516f5a255e; the branch was not checked out or executed.
Contributor
✅
|
Pinning the ascoachingogvaner and wedding-app OCIRepository refs moves the aggregate authorization-surface fingerprint, because Flux source resources are authorization-capable and their projected text is covered by it. Membership is unchanged and no per-resource hash moved; the delta is two spec.ref fields swapping a floating semver range for a fixed tag, which narrows what may be reconciled. Fingerprint read from the required job on the approved renderer, measured after updating onto current main.
Code Coverage OverviewLanguages: Go Go / code-coverage/goThe overall coverage in commit 977478b in the Show a code coverage summary of the most covered files.
Updated |
…e tags Merge main and correct both pins. The branch pinned ascoachingogvaner to 1.1.0 and wedding-app to 1.5.9 while production reconciles 1.13.4 and 1.15.10, so merging it would have rolled both tenants backward by many releases. Read-only prod evidence confirms the deployed revisions; both match each repository's latest release. The rendered-surface fingerprint is reset to main's approved value. The tag change moves the selected authorization surface, so CI's approved renderer must supply the new value — the local toolchain is kubectl v1.36.1 against the approved v1.36.2 and is refused.
Contributor
Author
CI is green at the current head and no review has been requested on this PR yet. Requesting one. @coderabbitai review |
Contributor
|
🧠 Learnings used
|
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review. 📜 Recent review details🧰 Additional context used📓 Path-based instructions (1)**/*.{yaml,yml}📄 CodeRabbit inference engine (AGENTS.md)
Files:
🧠 Learnings (6)📚 Learning: 2026-07-01T21:13:36.950ZApplied to files:
📚 Learning: 2026-07-03T03:44:11.507ZApplied to files:
📚 Learning: 2026-08-08T15:10:00.349ZApplied to files:
📚 Learning: 2026-08-08T15:10:00.350ZApplied to files:
📚 Learning: 2026-08-08T21:23:32.529ZApplied to files:
📚 Learning: 2026-08-11T12:41:28.242ZApplied to files:
🔇 Additional comments (3)
📝 WalkthroughWalkthroughThe Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
Contributor
Author
@codex review |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Contributor
Author
CodeRabbit returned |
Contributor
Author
|
@cursor review |
Contributor
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_570b60eb-975d-4fd0-a0da-56e028c0f03a) |
# Conflicts: # scripts/validate-eks-ci-role-policy/main.go
Contributor
Author
Blocker: this PR's conflict is an authorization-surface re-measurement, not a mergeable conflict. Diagnosed, not resolved — recording it so the next pass starts from evidence.
Neither value is correct for the merge result, which is why this cannot be hand-merged. That constant is the aggregate fingerprint of the rendered RBAC surface; the branch's value was measured against an older The rest of the state is healthy: 28 checks green, 5 skipped, 0 failing, and the change itself (pinning tenant OCI manifest tags away from a What this needsThe two-renderer re-measurement on the merge result, with matched controls:
I stopped rather than hurry it: a hasty pass on a prod authorization fingerprint is worse than none. The branch is untouched and no partial merge was pushed. |
…semver-selection-vulnerability # Conflicts: # scripts/validate-eks-ci-role-policy/main.go
Contributor
Author
@coderabbitai review |
Contributor
|
🧠 Learnings used
🧠 Learnings used✅ Action performedReview finished.
|
Contributor
Author
Readiness evaluation @
Promoting and enqueuing. |
devantler
marked this pull request as ready for review
August 18, 2026 00:44
devantler
deleted the
codex/fix-tenant-oci-semver-selection-vulnerability
branch
August 18, 2026 00:52
devantler
added a commit
to devantler-tech/platform-tenant-template
that referenced
this pull request
Aug 18, 2026
* fix(tests): track the Platform tenant OCI pinned-tag change Platform pinned the manual tenant apps' OCI manifests to an exact tag in devantler-tech/platform#2737, replacing the floating ">=1.0.0" semver range. The envelope contract still asserted the semver form, so the whole conjunction matched nothing and CI failed with "no matches found". Assert the hardened shape instead: no semver range at all, and an exact pinned version tag. The generated RGD tenant still uses semver, so its assertion is deliberately unchanged. * fix(tests): reject leading-zero version components in the tenant OCI tag Addresses a CodeRabbit review finding: [0-9]+ accepted 01.2.3 and 1.13.04, which are not valid semver. Match each component as 0 or a non-zero digit followed by digits, which still accepts a legitimate zero component (0.1.0). * test(envelope): pin the tenant OCI pinned-tag predicate with mutants The pinned-tag predicate had no committed mutant, so a future weakening of it would pass the whole safety suite. Add four rejecting mutations covering a floating tag, a restored semver range, and a leading-zero version component in both the major and patch positions. The two leading-zero mutants are not redundant: each version component is anchored separately, so a partial revert that tightens only the major component still rejects "01.2.3" while accepting "1.2.03". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(envelope): pin the minor version component too Self-review found the same gap one level down: the major and patch positions each had a leading-zero mutant, but the minor position did not, so a partial revert tightening only major and patch would still have passed the suite. Ablation proof: with the predicate weakened to "^(0|[1-9][0-9]*)[.][0-9]+[.](0|[1-9][0-9]*)$" the suite fails specifically on "manual OCI tag minor component leading zero". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Both tenant apps tracked their manifests with an open-ended
>=1.0.0range, so Flux automatically selected and deployed any newer tag pushed to that registry path. Whoever can publish a tag chose what production runs, with no review in between.What
Pins each tenant to the exact manifest revision production is already reconciling, so tenant deployments become a reviewed step rather than an unattended one. Nothing that is running changes.
Security/DevEx: the floor gains removal of unattended tag selection for both tenants; the everyday path is unchanged for app development — only a tenant manifest rollout now needs a pin bump.
k8s/bases/apps/<app>/oci-repository.yaml.