Stop insisting on chart version bump on stable branches also - #3217
Merged
Merged
Conversation
Member
Author
|
/assign @mandre |
mandre
reviewed
Sep 14, 2026
In PR kubernetes#3195 we modified the chart release process so that we no longer required a bump in the chart version on `master`. Unfortunately, we still have an issue on stable `release-*` branches. Anyone that backports a fix using the `/cherry-pick` slash command will see a failing chart lint job on said stable branch. This can only be fixed by incrementing the `version` field, but no one (including the maintainers) has the ability to push to the `k8s-infra-cherrypick-robot` repo fork that the bot uses. This means the only practical way to backport fixes that include chart changes is to do so manually, which is a lot more work for very little gain. Rather than doing this, drop the version check entirely. This means we will have to manually bump the chart version periodically, but that's not a huge ask and is very similar to what we already do for CPO itself. To make this easier, we make the `hack/bump-version.sh` smarter so that it can start automatically bumping chart versions. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Encourage users to run the master version of the release script (it doesn't exist on older branches). Also explain the meaning of the 3 chart-only tags. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
stephenfin
force-pushed
the
chart-lint
branch
from
September 14, 2026 15:06
9bce4dd to
35129f3
Compare
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mandre The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
What this PR does / why we need it:
In PR #3195 we modified the chart release process so that we no longer required a bump in the chart version on
master. Unfortunately, we still have an issue on stablerelease-*branches. Anyone that backports a fix using the/cherry-pickslash command will see a failing chart lint job on said stable branch. This can only be fixed by incrementing theversionfield, but no one (including the maintainers) has the ability to push to thek8s-infra-cherrypick-robotrepo fork that the bot uses. This means the only practical way to backport fixes that include chart changes is to do so manually, which is a lot more work for very little gain.Rather than doing this, drop the version check entirely. This means we will have to manually bump the chart version periodically, but that's not a huge ask and is very similar to what we already do for CPO itself. To make this easier, we make the
hack/bump-version.shsmarter so that it can start automatically bumping chart versions.While here, we also improve the release procedure doc further, clarifying the purpose of different tags and the instances where you should bump different fields.
Which issue this PR fixes(if applicable):
Ref #3194
Special notes for reviewers:
(none)
Release note: