kubernetes-sigs / kubernetes-sigs/node-readiness-controller

[BUG] Chart.yaml is never bumped, so installing the chart from source deploys the previous release

Closed Beginner friendly
#452 0 comments 0 reactions 0 assignees View on GitHub

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
  1. git checkout v0.5.0
  2. helm template x ./charts/node-readiness-controller --show-only templates/deployment.yaml | grep image:
  3. The tag is v0.4.1, not v0.5.0.
  4. make -n build-helm shows --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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.