-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update helm chart to v0.26.0 #1038
Conversation
Ah
So it looks like the updated helm chart version attempts to get installed. I'm thinking maybe this is the behavior now after #911? @knelasevero any ideas for that? Some ways around this for releases:
We use the helm chart change as the final "no-op" merge to trigger a build with the proper git tag (https://github.com/kubernetes-sigs/descheduler/blob/master/docs/release-guide.md#flowchart). But this step could be replaced with another non functional change such as readme updates. The important part is that functional code is merged before tagging the release in Git, followed by another GCB build to pull in the new git tag. If there's no easy change to #911 we could make now, I'll just open a no-op docs change or something to trigger the build. Or manually trigger it |
Option 2 doesn't seem so bad. Another option would be to add a step to the GitHub Action to query the latest image release and use that as the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
prefer option 2 (Build/tag the v0.26.0 image before merging the helm chart change) |
1 similar comment
prefer option 2 (Build/tag the v0.26.0 image before merging the helm chart change) |
In option 2 do you mean building locally and then pushing the image? |
➕
This is indeed an option, and not that hard to make I guess, but I agree that it is confusing. Probably having a doc change to be the no op step and then the helm chart step coming next is the best friction-less option going forward, and building it locally and pushing is ok to unblock this PR here? |
We actually have some other changes under the v0.26.0 tag (like #995), so for this release that should be able to promote to the public image. For the next release we'll need to think about this. It also might be good to add a "release-mode" blocker so that PRs don't merge automatically or accidentally while we're doing the release process. |
/retest |
Successful image tag, I'll work on updating the process for next release to address this. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: a7i The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes #1020