Update helm chart to v0.26.0

[damemi]

Fixes #1020

[damemi]

Ah

Failed to pull image "registry.k8s.io/descheduler/descheduler:v0.26.0": rpc error: code = NotFound desc = failed to pull and unpack image "registry.k8s.io/descheduler/descheduler:v0.26.0": failed to resolve reference "registry.k8s.io/descheduler/descheduler:v0.26.0": registry.k8s.io/descheduler/descheduler:v0.26.0: not found

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:

1. roll back/change introduce ct for local helm install test #911
2. Build/tag the v0.26.0 image before merging the helm chart change.
3. manually trigger the v0.26.0 image build (if possible? this could be the right way to do things going forward)

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

[a7i]

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 AppVersion. In other words, always use the latest published image but it does seem add a bit of confusion as it would not use the AppVersion defined in the Chart.

[JaneLiuL]

/lgtm

[JaneLiuL]

prefer option 2 (Build/tag the v0.26.0 image before merging the helm chart change)

[JaneLiuL]

prefer option 2 (Build/tag the v0.26.0 image before merging the helm chart change)

[knelasevero]

In option 2 do you mean building locally and then pushing the image?

[knelasevero]

If there's no easy change to #911 we could make now

➕

Another option would be to add a step to the GitHub Action to query the latest image release and use that as the AppVersion. In other words, always use the latest published image but it does seem add a bit of confusion as it would not use the AppVersion defined in the Chart.

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?

[damemi]

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.

[damemi]

/retest

[damemi]

Successful image tag, I'll work on updating the process for next release to address this.

[a7i]

/approve

[k8s-ci-robot]

[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:

• OWNERS [a7i]

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