Skip to content

This page documents the release process of the SF operator.

CHANGELOG Management

We follow the guidelines of Keep a Changelog to manage our CHANGELOG.

Before tagging, please make sure the CHANGELOG is up to date:

  1. Rename the [in development] section to the next tag, followed by the UTC date as YYYY-MM-DD of the tag (for example [v0.0.20] - 2023-12-31)
  2. Remove any empty sections in the release block
  3. Prepend a template [in development] section like so:
## [in development]

### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security

Then commit the changes to the CHANGELOG for review, and have them validated and merged. This change should be the last one before tagging.

Tagging

Note

Only core contributors have the right to push a tag on the sf-operator repository. If you aren't a core contributor but would like to suggest the creation of a new tag, please contact us on our matrix channel.

Here are the commands to run (assuming releasing HEAD to v0.0.20 version):

git checkout master
git pull origin master
git tag v0.0.20 HEAD
git push gerrit v0.0.20

Release Automation

A CD job named sf-operator-publish-olm-bundle-image runs in the release pipeline. The release pipeline is triggered when a git tag is created on the sf-operator repository. This job builds and pushes the following assets to Quay.io:

Clusters where the operator is installed through OLM will upgrade automatically to the latest released version.