chore: point the operator chart at the 0.6.1 image - #233
Merged
Conversation
appVersion drives the operator image tag (image.tag defaults to .Chart.AppVersion), and it still named 0.6.0 while two fixes had landed in the code that image is built from: the tenant egress rules now derived from spec.datastores, and the relational default moved to an Aurora major line. A chart published at 0.6.0 would carry both fixes in its CRDs and neither in the binary reconciling them. Chart 0.6.7 rather than 0.6.6. 0.6.6 was never published — the registry check confirms it — but the chart's contents move here, and the CI gate compares content against the merge base rather than against the registry. Bumping is cheaper than arguing the distinction, and an unpublished version number costs nothing to skip. Released in order, because the drift gate enforces it: the image tag goes first (operator-v0.6.1), then the chart is pointed at what exists. A chart naming an image nobody built is the failure that gate was written for.
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.
appVersiondrives the operator image tag (image.tagdefaults to.Chart.AppVersion), and it still named 0.6.0 while two fixes had landed in the code that image is built from:spec.datastores(fix: let a tenant reach the datastores it declared #232)A chart published at
appVersion: 0.6.0would ship both fixes in its CRDs and neither in the binary reconciling them — the operator would be enforcing a CRD it doesn't understand.Order matters here
The drift gate enforces it, and this PR is the second half:
operator-v0.6.1tag → builds, signs and pushes the imageA chart naming an image nobody built is exactly the failure that gate was written for — the header on
release.yamlrecords the timeappVersionrode in on a feature commit with no tag behind it and every syncing cluster gotImagePullBackOffon the operator itself.Why 0.6.7, not 0.6.6
0.6.6was never published —check-chart-version-bump.py --publishedconfirms "operator 0.6.6 — not yet published". But CI also runs--base origin/main, which compares content against the merge base rather than the registry, and that mode correctly sees the chart's bytes moving. Bumping is cheaper than arguing the distinction, and skipping an unpublished version number costs nothing.This does mean the eks-gitops pin moves
0.6.5 → 0.6.7, not→ 0.6.6.All three gate modes pass locally:
--self-test(7 cases),--base origin/main,--published.