Skip to content

fix: stamp the chart with a real version outside the release pipeline - #453

Open
tejassinghbhati wants to merge 1 commit into
kubernetes-sigs:mainfrom
tejassinghbhati:fix/chart-version-metadata
Open

fix: stamp the chart with a real version outside the release pipeline#453
tejassinghbhati wants to merge 1 commit into
kubernetes-sigs:mainfrom
tejassinghbhati:fix/chart-version-metadata

Conversation

@tejassinghbhati

Copy link
Copy Markdown
Contributor

Description

Chart.yaml has carried version: 0.1.0 and appVersion: "v0.4.1" since the chart landed and is not bumped at release, so installing from a checkout deploys the previous release. This is still true at the v0.5.0 tag:

$ 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 published chart is correct because build-helm stamps it at package time, but RELEASE_VERSION is only ever set by scripts/build-and-publish.sh and is undefined in the Makefile. Running the documented target outside that script expands to --version "" --app-version "", which helm package does not reject. It falls back to Chart.yaml and quietly emits a 0.1.0 chart pinned to v0.4.1.

So this does two things. RELEASE_VERSION now defaults to the VERSION file, which already holds the release being cut, and Chart.yaml is synced with it.

Bumping Chart.yaml on its own would fix the install path but leave make build-helm dependent on the publish script, which is why both are here.

Related Issue

Fixes #452

Type of Change

/kind bug

Testing

Source install now deploys the right image:

$ 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.5.0"

The publish path is unaffected, since ?= yields to the environment:

$ 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"

helm unittest --strict passes, 37 tests across 6 suites. helm lint clean. The bundled CRD still matches config/crd/bases, so verify-chart-drift.sh is unaffected.

The RELEASE.md line is the part that stops it recurring. Step 2 already lists the VERSION file and releases.md but not Chart.yaml, which is why it never moved. Same shape as #395.

Checklist

  • make test passes
  • make lint passes

Does this PR introduce a user-facing change?

Fixed the Helm chart's version and appVersion being stale, which caused installs from a source checkout to deploy the previous controller release. `make build-helm` now stamps the chart from the VERSION file instead of silently emitting an unversioned one.

Chart.yaml has carried version 0.1.0 and appVersion v0.4.1 since the
chart landed, and neither is bumped at release. At the v0.5.0 tag it
still reads v0.4.1, so anyone installing the chart from a checkout gets
the previous release of the controller.

  $ git checkout v0.5.0
  $ helm template x ./charts/node-readiness-controller | grep image:
    image: "registry.k8s.io/node-readiness-controller/node-readiness-controller:v0.4.1"

The published chart is correct because build-helm stamps it at package
time, but RELEASE_VERSION is only ever set by scripts/build-and-publish.sh
and is undefined in the Makefile. Running make build-helm outside that
script therefore expands to --version "" --app-version "", which helm
does not reject. It quietly falls back to Chart.yaml and produces a
0.1.0 chart pinned to v0.4.1.

Default RELEASE_VERSION to the VERSION file so the target is correct on
its own, and sync Chart.yaml with the current release so a plain helm
install from source deploys what the checkout says it will. The
publishing script still overrides both, and ?= leaves that path
untouched.

Also adds the Chart.yaml bump to the release checklist, which is what
kept it stale.

Signed-off-by: tejassinghbhati <tejassinghbhati077@gmail.com>
@kubernetes-prow kubernetes-prow Bot added the kind/bug Categorizes issue or PR as related to a bug. label Aug 25, 2026
@netlify

netlify Bot commented Aug 25, 2026

Copy link
Copy Markdown

Deploy Preview for node-readiness-controller canceled.

Name Link
🔨 Latest commit a27af3a
🔍 Latest deploy log https://app.netlify.com/projects/node-readiness-controller/deploys/6a8d113dbdb194000851fba8

@kubernetes-prow

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tejassinghbhati
Once this PR has been reviewed and has the lgtm label, please assign haircommander for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubernetes-prow kubernetes-prow Bot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Aug 25, 2026
@kubernetes-prow

Copy link
Copy Markdown

Hi @tejassinghbhati. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@kubernetes-prow kubernetes-prow Bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Aug 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant