fix: stamp the chart with a real version outside the release pipeline - #453
fix: stamp the chart with a real version outside the release pipeline#453tejassinghbhati wants to merge 1 commit into
Conversation
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>
✅ Deploy Preview for node-readiness-controller canceled.
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: tejassinghbhati The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
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 Tip We noticed you've done this a few times! Consider joining the org to skip this step and gain Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
Description
Chart.yamlhas carriedversion: 0.1.0andappVersion: "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 thev0.5.0tag:The published chart is correct because
build-helmstamps it at package time, butRELEASE_VERSIONis only ever set byscripts/build-and-publish.shand is undefined in the Makefile. Running the documented target outside that script expands to--version "" --app-version "", whichhelm packagedoes not reject. It falls back toChart.yamland quietly emits a0.1.0chart pinned tov0.4.1.So this does two things.
RELEASE_VERSIONnow defaults to theVERSIONfile, which already holds the release being cut, andChart.yamlis synced with it.Bumping
Chart.yamlon its own would fix the install path but leavemake build-helmdependent 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:
The publish path is unaffected, since
?=yields to the environment:helm unittest --strictpasses, 37 tests across 6 suites.helm lintclean. The bundled CRD still matchesconfig/crd/bases, soverify-chart-drift.shis unaffected.The
RELEASE.mdline is the part that stops it recurring. Step 2 already lists theVERSIONfile andreleases.mdbut notChart.yaml, which is why it never moved. Same shape as #395.Checklist
make testpassesmake lintpassesDoes this PR introduce a user-facing change?