Sok3t/descheduler
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/descheduler.git synced 2026-01-25 20:59:28 +01:00
Code Packages Releases Activity
Files
master
descheduler/docs/release-guide.md
Kensei Nakada 2a27d1be90 fix: update the mailing list address
2025-04-30 17:40:53 +02:00

7.0 KiB
Raw Permalink Blame History

Release Guide

The process for publishing each Descheduler release includes a mixture of manual and automatic steps. Over time, it would be good to automate as much of this process as possible. However, due to current limitations there is care that must be taken to perform each manual step precisely so that the automated steps execute properly.

Pre-release Code Changes

Before publishing each release, the following code updates must be made:

  • (Optional, but recommended) Bump k8s.io dependencies to the -rc tags. These tags are usually published around upstream code freeze. Example
  • Bump k8s.io dependencies to GA tags once they are published (following the upstream release). Example
  • Ensure that Go is updated to the same version as upstream. Example
  • Make CI changes in github.com/kubernetes/test-infra to add the new version's tests (note, this may also include a Go bump). Example
  • Update local CI versions for utils (such as golang-ci), kind, and go. Example - e2e, Example - helm
  • Update version references in docs and Readme. Example

Release Process

When the above pre-release steps are complete and the release is ready to be cut, perform the following steps in order (the flowchart below demonstrates these steps):

Version release

  1. Create the git tag on master for the release, eg v0.24.0
  2. Merge Helm chart version update to master (see Helm chart below). Example
  3. Perform the image promotion process. Example
  4. Cut release branch from master, eg release-1.24
  5. Publish release using Github's release process from the git tag you created
  6. Email sig-scheduling@kubernetes.io to announce the release

Patch release

  1. Pick relevant code change commits to the matching release branch, eg release-1.24
  2. Create the patch tag on the release branch, eg v0.24.1 on release-1.24
  3. Merge Helm chart version update to release branch
  4. Perform the image promotion process for the patch version
  5. Publish release using Github's release process from the git tag you created
  6. Email sig-scheduling@kubernetes.io to announce the release

Flowchart

Flowchart for major and patch releases

Image promotion process

Every merge to any branch triggers an image build and push to a gcr.io repository. These automated image builds are snapshots of the code in place at the time of every PR merge and tagged with the latest git SHA at the time of the build. To create a final release image, the desired auto-built image SHA is added to a file upstream which copies that image to a public registry.

Automatic builds can be monitored and re-triggered with the post-descheduler-push-images job on prow.k8s.io.

Note that images can also be manually built and pushed using VERSION=$VERSION make push-all by users with access.

Helm Chart

We currently use the chart-releaser-action GitHub Action to automatically publish Helm chart releases. This action is triggered when it detects any changes to Chart.yaml on a release-* branch.

Helm chart releases are managed by a separate set of git tags that are prefixed with descheduler-helm-chart-*. Example git tag name is descheduler-helm-chart-0.18.0. Released versions of the helm charts are stored in the gh-pages branch of this repo.

The major and minor version of the chart matches the descheduler major and minor versions. For example descheduler helm chart version helm-descheduler-chart-0.18.0 corresponds to descheduler version v0.18.0. The patch version of the descheduler helm chart and the patcher version of the descheduler will not necessarily match. The patch version of the descheduler helm chart is used to version changes specific to the helm chart.

  1. Merge all helm chart changes into the master branch before the release is tagged/cut
    1. Ensure that appVersion in file charts/descheduler/Chart.yaml matches the descheduler version(no v prefix)
    2. Ensure that version in file charts/descheduler/Chart.yaml has been incremented. This is the chart version.
  2. Make sure your repo is clean by git's standards
  3. Follow the release-branch or patch release tagging pattern from the above section.
  4. Verify the new helm artifact has been successfully pushed to the gh-pages branch

Notes

The Helm releaser-action compares the changes in the action-triggering branch to the latest tag on that branch, so if you tag before creating the new branch there will be nothing to compare and it will fail. This is why it's necessary to tag, eg, v0.24.0 before making the changes to the Helm chart version, so that there is a new diff for the action to find. (Tagging after making the Helm chart changes would also work, but then the code that gets built into the promoted image will be tagged as descheduler-helm-chart-xxx rather than v0.xx.0).

See post-descheduler-push-images dashboard for staging registry image build job status.

View the descheduler staging registry using this URL in a web browser or use the below gcloud commands.

List images in staging registry.

gcloud container images list --repository gcr.io/k8s-staging-descheduler

List descheduler image tags in the staging registry.

gcloud container images list-tags gcr.io/k8s-staging-descheduler/descheduler

Get SHA256 hash for a specific image in the staging registry.

gcloud container images describe gcr.io/k8s-staging-descheduler/descheduler:v20200206-0.9.0-94-ge2a23f284

Pull image from the staging registry.

docker pull gcr.io/k8s-staging-descheduler/descheduler:v20200206-0.9.0-94-ge2a23f284
View Git Blame Copy Permalink