fix: publish the real chart version to the GitHub Pages index - #822
Open
Yetkin Timocin (ytimocin) wants to merge 2 commits into
Open
fix: publish the real chart version to the GitHub Pages index#822Yetkin Timocin (ytimocin) wants to merge 2 commits into
Yetkin Timocin (ytimocin) wants to merge 2 commits into
Conversation
The GitHub Pages publish never passed chart_version/app_version to helm-gh-pages, so it packaged charts/*/Chart.yaml verbatim - both pinned in-tree at version 0.1.0, appVersion v0.1.0. Every release republished "hub-agent 0.1.0" and "member-agent 0.1.0", and because `helm repo index --merge` lets the newly generated entry win a version collision, each release silently replaced the contents of that same 0.1.0 tarball rather than adding a version. The live index still lists only 0.1.0. The OCI publish has always passed both values via `make helm-push`, so this affects the `helm repo add` channel only. For users of that channel, `helm install kubefleet/hub-agent` with no --version has always resolved to 0.1.0, and since the chart defaults image.tag to .Chart.AppVersion, those installs have been running v0.1.0 images. After this change the same command resolves to the current release. charts/README.md now carries that warning at the bare install and upgrade commands, drops a --version example that never existed on this channel, and stops telling contributors to bump Chart.yaml fields the pipeline overrides. The stale 0.1.0 entry survives the index merge and still appears in `helm search repo kubefleet --versions`; removing it would break anyone pinning it, so it is left alone here. Nothing already published is modified or deleted by this change. A verification step reads the gh-pages branch back and fails the job unless each chart was published with the release tag as its appVersion and listed in index.yaml - the file `helm repo add` actually reads. Unknown inputs to an action are only a warning, so a rename or typo would otherwise restore the old behaviour with a green build. Part of kubefleet-dev#693. Signed-off-by: Yetkin Timocin <ytimocin@microsoft.com>
Yetkin Timocin (ytimocin)
added
process-improvement
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Contributor
There was a problem hiding this comment.
Pull request overview
Publishes correct release versions to the GitHub Pages Helm index and documents the resulting upgrade impact.
Changes:
- Passes chart and application versions to
helm-gh-pages. - Verifies published archives and index entries.
- Updates installation, upgrade, and contribution guidance.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.github/workflows/chart.yml |
Publishes and verifies release-versioned charts. |
charts/README.md |
Documents versioning behavior and migration impact. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+54
to
+59
| > **Heads up if you already use this repository.** Until recently every release | ||
| > was published here as chart version `0.1.0` with `appVersion v0.1.0`, so an | ||
| > install from this channel that did not set `image.tag` has been running the | ||
| > `v0.1.0` images. Releases now publish their real version, which means the | ||
| > commands below resolve to the current release rather than to `0.1.0`. The OCI | ||
| > registry above was never affected. |
Comment on lines
+197
to
+199
| 1. Leave `version` and `appVersion` in `Chart.yaml` alone — the release | ||
| workflow injects the release version at package time, so the in-tree values | ||
| are placeholders and are not what gets published |
The warning added alongside the index fix said users had "been running the v0.1.0 images". That is not what happened, and the correction matters because the real outcome is worse for some readers and harmless for others. Walking all 50 revisions of the published tarball on gh-pages: until March 2026 the chart pinned image.tag: main against ghcr.io/azure/fleet. That tag exists and pullPolicy is Always, so those installs came up fine and have been re-pulling unreleased builds on every pod restart ever since - and ghcr.io/azure/fleet/hub-agent:main is still being rebuilt today, from outside this repository's release process. Only installs from February 2026 onward hit ImagePullBackOff, because 0.1.0 and v0.1.0 were never pushed to ghcr.io/kubefleet-dev/kubefleet. The two eras also interleaved rather than replacing each other, so what a cluster runs depends on when it last ran `helm repo update` rather than on any release. Replace the single claim with a table of what that one 0.1.0 slot served over time, ordered by severity, and broaden the diagnostic: the tell is any image that is not a release tag, not only :v0.1.0. A reader in the first row has no symptom to notice. Also drop two claims that did not survive checking: the OCI channel was not "never affected" (chart 0.1.0 pins the same floating tag, and 0.2.1-test names a missing image), and earlier releases were not "available from the OCI registry only" - no chart carrying its own release version exists for them anywhere. Fold six near-duplicate warnings into one section the others link to, which also fixes an anchor that pointed at a restatement rather than at the guidance. Add an "am I affected" command and an upgrade recipe that re-passes member-agent's hub connection, since a bare upgrade resets it to the chart's placeholders. Chart.yaml comments told contributors to bump version and appVersion on every change, contradicting the rule this PR documents. They are release-time placeholders, and installing from a git checkout needs --set image.tag because of it. member-agent's parameter table documented four wrong defaults, including image.tag: v0.1.0 - the exact broken value - and omitted the refresh-token image entirely. Signed-off-by: Yetkin Timocin <ytimocin@microsoft.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
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.
The GitHub Pages publish never passed
chart_version/app_versiontohelm-gh-pages, so it packagedcharts/*/Chart.yamlverbatim — both pinned in-tree at0.1.0/v0.1.0. Every release republishedhub-agent 0.1.0andmember-agent 0.1.0, and becausehelm repo index --mergelets the newly generated entry win a version collision, each release silently replaced the contents of that same0.1.0tarball rather than adding a version. The live index still lists only0.1.0.The OCI publish has always passed both values via
make helm-push, so this affects thehelm repo addchannel only.User impact on that channel.
helm install kubefleet/hub-agentwith no--versionhas always resolved to0.1.0, and since the chart defaultsimage.tagto.Chart.AppVersion, those installs have been runningv0.1.0images. After this change the same command resolves to the current release, so a firsthelm upgradecan cross several releases at once.charts/README.mdnow carries that warning at the bare install and upgrade commands, drops a--version 0.3.0example that never existed on this channel, and stops telling contributors to bumpChart.yamlfields the pipeline overrides.The stale
0.1.0entry survives the index merge and still appears inhelm search repo kubefleet --versions. Removing it would break anyone pinning it, so it is left alone here. Nothing already published is modified or deleted by this PR — the change takes effect at the next stable tag.A verification step reads the
gh-pagesbranch back and fails the job unless each chart was published with the release tag as itsappVersionand listed inindex.yaml, the filehelm repo addactually reads. Unknown inputs to an action are only a warning, so a rename or typo would otherwise restore the old behaviour with a green build.Part of #693.