fix: 28 ApplicationSets pinned main while app-of-apps tracked the revision - #201
Merged
Merged
Conversation
CI Results
All checks passed. |
…ision `cluster-bootstrap` stamps two sibling annotations on every ArgoCD cluster Secret, `gitops/repo-url` and `gitops/repo-branch`, and the comment above them says appsets template their own source off these so no org is hardcoded in the manifests. That was true of repo-url — 33 files read it. repo-branch had exactly one reference in the whole org: the line that writes it. Meanwhile 28 applied ApplicationSets carried `targetRevision: main` as a literal, directly beneath a repoURL templated off the annotation. So a cluster bootstrapped against any other revision ran app-of-apps at that revision — the Application does honour var.gitops_repo_branch — and every child Application at main. Both report Synced and Healthy: ArgoCD is telling the truth about each Application individually, and the cluster is running two revisions of the catalog at once with nothing anywhere to say so. Two things that makes impossible. Testing a catalog change on a branch: the cluster syncs main's values while app-of-apps displays the branch name, which is exactly the evidence someone would check. And pinning a release: a platform installed from a tag gets a tagged app-of-apps over an unpinned fleet, so "deploy the known-good version" deploys HEAD. Every catalog source now reads the annotation. Chart sources are untouched and must be — their repoURL is a Helm or OCI registry and their targetRevision is a chart version, a different thing sharing a field name. The render fixtures gain the annotation, which is load-bearing rather than housekeeping: the appsets run with goTemplateOptions missingkey=error, so a cluster Secret without it now fails the render instead of silently defaulting. `scripts/check-catalog-revision.py` holds it. It parses each applied ApplicationSet, finds the sources whose repoURL resolves from gitops/repo-url, and asserts their targetRevision resolves from gitops/repo-branch. It also fails when it finds ZERO catalog sources — every addon gets its values files through one, so none means the parse broke rather than the repo being clean.
stxkxs
force-pushed
the
feat/catalog-revision-is-load-bearing
branch
from
August 9, 2026 18:06
f4a8375 to
122edf4
Compare
CI Results
All checks passed. |
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.
cluster-bootstrapstamps two sibling annotations on every ArgoCD cluster Secret,gitops/repo-urlandgitops/repo-branch, and the comment above them says appsets template their own source off these so no org is hardcoded in the manifests. That is true ofrepo-url— 33 files read it.repo-branchhad exactly one reference in the whole org: the line that writes it.Meanwhile 28 applied ApplicationSets carried
targetRevision: mainas a literal, directly beneath arepoURLtemplated off the annotation.So a cluster bootstrapped against any other revision ran
app-of-appsat that revision — the Application does honourvar.gitops_repo_branch— and every child Application atmain. Both report Synced and Healthy. ArgoCD is telling the truth about each Application individually, and the cluster is running two revisions of the catalog at once with nothing anywhere to say so.Two things that makes impossible:
main's values whileapp-of-appsdisplays the branch name — which is exactly the evidence someone would check.Closes #238 by taking its option 1: make the annotation load-bearing.
Scope
Every catalog source now reads the annotation. Chart sources are untouched and must be — their
repoURLis a Helm or OCI registry and theirtargetRevisionis a chart version, a different thing that happens to share a field name.The render fixtures gain the annotation, and that is load-bearing rather than housekeeping: the appsets run with
goTemplateOptions: missingkey=error, so a cluster Secret without it now fails the render instead of silently defaulting to something.The gate
scripts/check-catalog-revision.pyparses each applied ApplicationSet, finds the sources whoserepoURLresolves fromgitops/repo-url, and asserts theirtargetRevisionresolves fromgitops/repo-branch.It also fails when it finds zero catalog sources. Every addon gets its values files through one, so none means the parse broke rather than the repo being clean — a gate that finds nothing to check has stopped checking.
Paired with rackctl, which is gaining a
versions:block: pinning the catalog locally is inert while the fleet syncsmainregardless.