Skip to content

How To: Release Updates

Jump to bottom
Joe McCormick edited this page Feb 29, 2024 · 9 revisions

Overview

This page contains a summary of things that should be completed with each release of the driver and operator.

Preparing to Release

These steps can be performed anytime after the previous release:

  • The GitHub Actions E2E tests should be updated to include the BeeGFS and Kubernetes versions supported by this release.
  • Documentation:
    • The Interoperability and CSI Feature Matrix in the README (in particular the driver version) must be updated.
    • Search for the previous semantic version across the repository and make any appropriate updates to the deployment guide and any other documentation/examples.
  • CHANGELOG must be updated.

Immediately Before Release

As soon as a release candidate is ready (commit identified we plan to tag as the release):

Releasing the Driver and Operator

  • With the master branch checked out, identify and tag the desired commit (e.g., git tag -a v1.0.0 -m "Version 1.0.0").

  • Push the tag (e.g., git push origin v1.0.0) and verify container images for the driver and operator are published.

  • Create a release branch (e.g., release-1.0).

  • Create a release in GitHub and copy the CHANGELOG contents.

Verify Release

  • Pull the tagged version of the driver image and verify its version: docker run --rm -it ghcr.io/thinkparq/beegfs-csi-driver:latest --version.
  • Verify the driver and operator images are properly signed using Cosign and the public key for this release.
    • Update the release with the images by digest and cosign commands including the URL to the public key (cosign.pub) for this release.

Publishing the Operator

Overview

While the operator is released by the steps in the previous section, we also publish it to operatorhub.io and OpenShift. For this to happen the operator bundle must be submitted to two separate repositories:

IMPORTANT: The following example demonstrates submission to the former, but the steps MUST be repeated for the latter.

If you have never established a fork:

Fork k8s-operatorhub/community-operators on GitHub using your personal account.

Clone your fork and set it up to track the upstream as well:

# Specify the directory community-operators-operatorhub to distinguish from community-operators-openshift.
git clone git@github.com:iamjoemccormick/community-operators.git community-operators-operatorhub
cd community-operators-operatorhub
git remote add upstream git@github.com:k8s-operatorhub/community-operators.git

If you previously established a fork:

Update your local main branch with upstream changes and push them to your fork:

git pull upstream main
git push origin main

Either way:

  • Create a new branch (e.g. beegfs-csi-driver-v1.2.0).
  • Create a new release directory in the beegfs-csi-driver-operator directory (e.g. beegfs-csi-driver-operator/1.5.0 ).
  • Check out the released version of the beegfs-csi-driver project and copy the contents of the operator/bundle directory into this new directory.
  • Commit the changes and push them to your fork. (IMPORTANT: Include the "Signed-off-by" line in your commit message according to the external project guidelines ).
git checkout -b beegfs-csi-driver-v1.5.0

# Make the necessary edits before continuing. For example:
cd operators/beegfs-csi-driver-operator/
cp -r ~/development/beegfs-csi-driver/operator/bundle 1.5.0

git add .
git commit -m "Add BeeGFS CSI driver v1.5.0

Signed-off-by: McCormick, Joe <31295332+iamjoemccormick@users.noreply.github.com>"  # Notice these lines create a multiline commit message.
git push --set-upstream origin beegfs-csi-driver-v1.5.0

OR use the -s option:

git commit -m "Add BeeGFS CSI driver v1.5.0" -s
git log // Verify the commit message is properly formatted.
git push --set-upstream origin beegfs-csi-driver-v1.5.0
  • Use the GitHub GUI to submit a pull request from your branch to upstream/main.
  • Wait for tests/checks to complete and fix any issues that arise.
    • Depending on what checks failed, you may not need to re-release the driver and/or operator and can simply fix the bundle. For example if there is some new field that needs to be set in the bundle. In this scenario update the bundle in the beegfs-csi-driver repo, unstage the commit in the affected community-operator fork(s) with git reset HEAD^, copy the updated bundle then commit and force push the changes with git push --force. This will also force push the commit to your PR(s). Once the checks are all passing don't forget to commit the updated bundle to the master branch of the beegfs-csi-driver repo.

Verify Published Operator

Note we no longer have an easy way to verify the operator published for OpenShift.

Clone this wiki locally