Release Guide

  • Updating CHANGELOG.md and migration guide.
  • Tagging and signing a git commit and pushing the tag to GitHub.
  • Building a release binary and signing the binary
  • Creating a release by uploading binary, signature, and CHANGELOG.md updates for the release to GitHub.
  • Creating a release branch of the form v1.2.x for each major and minor release.

Release steps can be found . If you have not run a release before we recommend reading through the sections directly following this one.

Release binaries will be built with the Go compiler version specified in the Operator SDK’s prerequisites section.

Kubernetes versions

As the Operator SDK interacts directly with the Kubernetes API, certain API features are assumed to exist in the target cluster. The currently supported Kubernetes version will always be listed in the SDK prerequisites section.

Operating systems and architectures

Release binaries will be built for the x86_64 architecture for MacOS Darwin platform and for the following GNU Linux architectures: x86_64, ppc64le, arm64, and s390x.

Base images for ansible-operator, helm-operator, and scorecard-test will be built for the following GNU Linux architectures: x86_64, ppc64le, and arm64.

Support for the Windows platform is not on the roadmap at this time.

Binaries and signatures

Binaries will be signed using a maintainers’ verified GitHub PGP key. Both binary and signature will be uploaded to the release. Ensure you import maintainer keys to verify release binaries.

Every release will have a corresponding git semantic version tag beginning with v, ex. v1.2.3.

Make sure you’ve and configured git to use that signing key either globally or for the Operator SDK repository. Tagging will be handled by release.sh.

Note: the email the key is issued for must be the email you use for git.

Also, make sure that you setup the git gpg config as follows.

  1. $ cat ~/.gnupg/gpg.conf
  2. default-key $GPG_KEY_ID

NOTE If you do a release from an OSX machine, you need to configure gnu-gpg to sign the release’s tag:

  • Install the requirements by running: brew install gpg2 gnupg pinentry-mac
  • Append the following to your ~/.bash_profile or ~/.bashrc or ~/.zshrc
  1. export GPG_TTY=`tty`
  • Restart your Terminal or source your ~/.*rc file
  1. $ git config --global gpg.program gpg2
  • To make sure gpg2 itself is working
  1. $ echo "test" | gpg2 --clearsign

Release branches

Each minor release has a corresponding release branch of the form vX.Y.x, where X and Y are the major and minor release version numbers and the x is literal. This branch accepts bug fixes according to our backport policy.

After the minor release is made, this branch must be fast-forwarded to that release’s tag and a post-release PR made against this branch. See the for more details.

Cherry-picking

Once a minor release is complete, bug fixes can be merged into the release branch for the next patch release. Fixes can be added automatically by posting a /cherry-pick v1.3.x comment in the master PR, or manually by running:

  1. $ git checkout v1.3.x
  2. $ git checkout -b cherrypick/some-bug
  3. $ git cherry-pick "$GIT_COMMIT_HASH" # Hash of the merge commit to master.
  4. $ git push upstream cherrypick/some-bug

Create and merge a PR from your branch to v1.3.x.

Locking down branches

Once a release PR has been made and all tests pass, the SDK’s master branch, or release branch for patch releases, should be locked so commits cannot happen between the release PR and release tag push. To lock down a branch:

  1. Go to Settings -> Branches in the SDK repo.
  2. Under Branch protection rules, click Edit on the master or release branches rule.
  3. In section Protect matching branches of the Rule settings box, increase the number of required approving reviewers to its maximum allowed value.

Now only administrators (maintainers) should be able to force merge PRs. Make sure everyone in the relevant Slack channel is aware of the release so they do not force merge by accident.

Unlock master or release branch after the release has completed (after step 6 is complete) by changing the number of required approving reviewers back to 1.

Releasing

The GitHub Releases tab in the operator-sdk repo is where all SDK releases live. To create a GitHub release see the .

Release notes

The following sections, often directly copied from our , are used as release notes:

  1. [Version as title, ex. v1.2.3]
  3. ### Added
  4. - [Short description of feature added] (#PR)
  5. ...
  7. ### Changed
  8. - [Short description of change made] (#PR)
  9. ...
  11. ### Deprecated
  12. - [Short description of feature deprecated] (#PR)
  13. ...
  15. ### Removed
  16. - [Short description of feature removed] (#PR)
  17. ...
  19. ### Bug Fixes
  20. - [Short description of bug and fix] (#PR)
  21. ...

Release Signing

When a new release is created, the tag for the commit it signed with a maintainers’ gpg key and the binaries for the release are also signed by the same key. All keys used by maintainers will be available via public PGP keyservers such as pool.sks-keyservers.net.

For new maintainers who have not done a release and do not have their PGP key on a public keyserver, output your armored public key using this command:

Then, copy and paste the content of the outputted file into the Submit a key section on pool.sks-keyservers.net or any other public keyserver that synchronizes the key to other public keyservers. Once that is done, other people can download your public key and you are ready to sign releases.

To verify a git tag, use this command:

  1. $ git verify-tag --verbose "$TAG_NAME"

If you do not have the mantainers public key on your machine, you will get an error message similiar to this:

  1. $ git verify-tag --verbose "$TAG_NAME"
  2. object 61e0c23e9d2e217f8d95ac104a8f2545c102b5c3
  3. type commit
  4. tag v0.6.0
  5. tagger Ish Shah <ishah@redhat.com> 1552688145 -0700
  7. gpg: Signature made Fri Mar 15 23:15:45 2019 CET
  8. gpg:                using RSA key <KEY_ID>
  9. gpg: Can't check signature: No public key

To download the key, use the following command, replacing $KEY_ID with the RSA key string provided in the output of the previous command:

  1. $ gpg --recv-key "$KEY_ID"

To verify a release binary using the provided asc files see the

Release steps

These steps describe how to conduct a release of the SDK, upgrading from v1.2.0 to v1.3.0. Replace these versions with the current and new version you are releasing, respectively.

For major and minor releases, master should be locked between steps 3 and 6 so that all commits will be either in the new release or have a pre-release version, ex. v1.2.0+git. Otherwise commits might be built into a release that shouldn’t be. For patch releases, ensure all required bugs are , then the release branch v1.3.x should be locked down.

This step is to be preferably performed only during major releases. Update the OLM_VERSION variable in Makefile to the latest successful release of OLM. Run make bindata so that internal/bindata/olm is updated. Also, update the availableVersions map in internal/bindata/olm/versions.go to contain the version of OLM which you have specified in the Makefile.

Submit a PR with the changes and merge it with master.

Important:

  • Update OLM bindata just before starting the release so that we have the latest OLM version.
  • Verify that the release of OLM version which you specify in Makefile is successful.

2. Netlify configuration

Important: ensure a release branch-to-subdomain mapping exists in the SDK’s Netlify configuration prior to creating a release, ex. v1.3.x to https://v1-3-x.sdk.operatorframework.io. You can ping SDK to ensure a release branch is created prior to the release and that this mapping is created.

3. Create release branch for Netlify

The release branch must be created before the release occurs to appease the Netlify website configuration demons. You can do so by running the following before proceeding with the release, assuming the upstream SDK is the upstream remote repo:

  1. $ git checkout master
  2. $ git pull
  3. $ git checkout -b v1.3.x
  4. $ git push -u upstream v1.3.x

4. Create a PR for release version, CHANGELOG.md, and migration guide updates

Once all PR’s needed for a release have been merged, branch from master:

  1. $ git checkout master
  2. $ git pull

If making a patch release, check out the corresponding minor version branch:

  1. $ git checkout v1.2.x
  2. $ git pull

Create a new branch to push release commits:

Run the CHANGELOG and migration guide generator:

  1. $ GEN_CHANGELOG_TAG=v1.3.0 make changelog

Commit the following changes:

  • website/content/en/docs/installation/install-operator-sdk.md: update the linux and macOS URLs to point to the new release URLs.
  • : commit changes (updated by changelog generation).
  • website/content/en/docs/upgrading-sdk-version/v1.3.0.md: commit changes (created by changelog generation).
  • changelog/fragments/*: commit deleted fragment files (deleted by changelog generation).
    1. [[params.versions]]
    2.   version = "v1.3"
    3.   url = "https://v1-3-x.sdk.operatorframework.io"

5. Lock down proper branch

Create and merge a new PR for release-v1.3.0. Once this PR is merged, lock down the master or release branch to prevent further commits between this and step 7. See this section for steps to do so.

The top-level release.sh script will take care of verifying versions in files described in step 3, and tagging and verifying the tag, as well as building binaries and generating signatures by calling make release.

Prerequisites:

  • and gpg default PGP keys are set locally.
  • Your PGP key is publicly available in a .

  • For macOS users: GNU sed and make which are not installed by default. Install them with

    1. $ brew install gnu-sed make

    then ensure they are present in your $PATH.

Call the script with the only argument being the new SDK version:

  1. $ ./release.sh v1.3.0

operator-sdk release binaries and signatures will be in dist/. Both binary and signature file names contain version, architecture, and platform information; signature file names correspond to the binary they were generated from suffixed with .asc. For example, signature file operator-sdk-v1.3.0-x86_64-apple-darwin.asc was generated from a binary named operator-sdk-v1.3.0-x86_64-apple-darwin. To verify binaries and tags, see the verification section.

ansible-operator and helm-operator release binaries and signatures are similarly built for upload so make run can download them in their respective operator type projects. See for details.

Push tag v1.3.0 upstream, assuming upstream is the name of the upstream remote:

  1. $ git push upstream v1.3.0

Once this tag passes CI, go to step 6. For more info on tagging, see the release tags section.

Note: If CI fails for some reason, you will have to revert the tagged commit, re-commit, and make a new PR.

7. Fast-forward the latest and release branches

The latest branch points to the latest release tag to keep the main website subdomain up-to-date. Run the following commands to do so:

  1. $ git checkout latest
  2. $ git reset --hard tags/v1.3.0
  3. $ git push -f upstream latest

Similarly, to update the release branch, run:

8. Create a PR for post-release version updates

Check out a new branch from master or release branch and commit the following changes:

  • (Major and minor releases only) website/config.toml: update version_menu = "v1.3" to version_menu = "Releases".

Create a new PR for this branch targeting the master or release branch.

9. Releasing binaries, signatures, and release notes

The final step is to upload binaries, their signature files, and release notes from CHANGELOG.md for v1.3.0. To create a GitHub release:

  1. Go to the SDK Releases tab and click the Draft a new release button in the top right corner.
  2. Select the tag version v1.3.0, and set the title to v1.3.0.
  3. Copy and paste CHANGELOG.md updates under the v1.3.0 header into the description form (see ).
  4. Attach all binaries and .asc signature files to the release by dragging and dropping them.
  5. Click the Publish release button.

Note: if this is a pre-release, make sure to check the This is a pre-release box under the file attachment frame. If you are not sure what this means, ask another maintainer.

10. Unlock proper branch

Unlock the or release branch after the Github release is complete. See for steps to do so.

Send an email to the mailing list Post to Kubernetes slack in #kubernetes-operators and #operator-sdk-dev.

12. Bump open issues to the next release.

In the GitHub milestone, bump any open issues to the following release.