kubernetes-sigs / kubernetes-sigs/node-readiness-controller
[BUG] Chart.yaml is never bumped, so installing the chart from source deploys the previous release
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 164
- Forks
- 75
- Avg merge
- 8d 23h
- Merged PRs (30d)
- 13
Description
What happened?
charts/node-readiness-controller/Chart.yaml has carried version: 0.1.0 and appVersion: "v0.4.1" since the chart landed, and neither is bumped when a release is cut. At the v0.5.0 tag it still reads v0.4.1, so installing the chart from a source checkout deploys the previous release of the controller:
$ git checkout v0.5.0
$ helm template x ./charts/node-readiness-controller --show-only templates/deployment.yaml | grep image:
image: "registry.k8s.io/node-readiness-controller/node-readiness-controller:v0.4.1"
The deployment takes its tag from the chart metadata:
image: "{{ .Values.image.repository }}:{{ default .Chart.AppVersion .Values.image.tag }}"
The published chart is fine, because build-helm stamps it at package time:
$(HELM) package ./charts/node-readiness-controller \
--version "$(CHART_VERSION)" \
--app-version "$(RELEASE_VERSION)" \
$ helm show chart oci://registry.k8s.io/node-readiness-controller/charts/node-readiness-controller --version 0.5.0
appVersion: v0.5.0
version: 0.5.0
So the OCI install path is correct and the source path is a release behind.
There is a second half to this
RELEASE_VERSION is never defined in the Makefile. The only place it is set is scripts/build-and-publish.sh:
RELEASE_VERSION=${IMG_TAG} make build-helm
Run the documented target outside that script and both flags expand to empty:
$ make -n build-helm
go run helm.sh/helm/v3/cmd/helm@v3.15.1 package ./charts/node-readiness-controller \
--version "" \
--app-version "" \
helm package does not reject empty values. It ignores them and falls back to Chart.yaml, so the target silently produces node-readiness-controller-0.1.0.tgz pinned to v0.4.1 rather than failing. I expected an error here and there isn't one, which is what makes it easy to miss.
Steps to Reproduce
git checkout v0.5.0helm template x ./charts/node-readiness-controller --show-only templates/deployment.yaml | grep image:- The tag is
v0.4.1, notv0.5.0. make -n build-helmshows--version ""and--app-version "".
Expected Behavior
Installing the chart from a checkout should deploy the release that checkout corresponds to, and make build-helm should produce a correctly stamped chart without depending on the publish script to inject the version.
Proposed fix
Default RELEASE_VERSION to the VERSION file, which already holds the release being cut, and keep Chart.yaml in step with it:
RELEASE_VERSION ?= $(shell cat $(ROOT_DIR)/VERSION)
CHART_VERSION ?= $(shell echo "$(RELEASE_VERSION)" | sed 's/^v//')
?= leaves the publish path alone, since RELEASE_VERSION=${IMG_TAG} make build-helm still wins. Verified both directions:
$ make -n build-helm # --version "0.5.0" --app-version "v0.5.0"
$ RELEASE_VERSION=v9.9.9 make -n build-helm # --version "9.9.9" --app-version "v9.9.9"
Bumping Chart.yaml alone would fix the install path but leave make build-helm depending on the publish script, so both parts are needed.
This is the same shape as #395, where the install guide pinned a stale version because the release checklist did not mention it. RELEASE.md step 2 lists the VERSION file and releases.md but not Chart.yaml, which is why it never moved, so that line is worth adding too.
Controller Version / Image Tag
main, and reproduced at the v0.5.0 tag.
Kubernetes Version
Not version specific.
Additional Environment Details
I checked before filing. No open issue mentions Chart.yaml, appVersion or the chart version, and no open PR touches Chart.yaml. Chart versions before v0.5.0 are not affected because the chart did not exist at those tags.
PR to follow.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Makefile's build-helm target and charts/node-readiness-controller/Chart.yaml, then inspect VERSION, RELEASE.md, and releases.md. Run make -n build-helm and helm template against the chart to verify the version values. Done means source checkouts and standalone builds use the matching release version, with the release documentation covering Chart.yaml.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- build-system, devops, release
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100