diff --git a/operator/docs/operator/release.md b/operator/docs/operator/release.md index b92698841d6e4..eb165cb924949 100644 --- a/operator/docs/operator/release.md +++ b/operator/docs/operator/release.md @@ -15,9 +15,10 @@ toc: true This document will go over the design of the release process for the Loki Operator and how to release it. -# Design +## Design To release Loki Operator we need the following: + 1. Bump the Loki Operator version and generate the bundle manifests with `make bundle-all`; 2. Update the CHANGELOG.md with the new version; 3. Create a release tag and a release on GitHub; @@ -27,50 +28,53 @@ Loki Operator uses the GitHub [action release-please](https://github.com/google- In the following sections, we will go over how the workflows are configured. -## release-please +### release-please release-please automates CHANGELOG generation, the creation of GitHub releases, and version bumps. It does so by parsing the git history, looking for Conventional Commit messages, and creating release PRs. Once a release PR is merged release-please will create the release and it will again wait for a releasable unit before opening the next release PR. A releasable unit is a commit with one of the following prefixes: "feat", "fix", and "deps". The workflow that is responsible for the operator release-please is `.github/workflows/operator-release-please.yml`. Note that the operator release-please process is different from the one used by Loki. The operator release-please configuration lives in `operator/release-please-config.json`. Useful links: + - release-please [customizing releases documentation](https://github.com/googleapis/release-please/blob/main/docs/customizing.md) - release-please [config documentation](https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md#configfile) The following sub-section contains some notes on the Loki operator release-please configuration: + - Use of `bump-minor-pre-major` and `bump-patch-for-minor-pre-major`; - Use of `draft`; - Preventing merging the release-please PR without updating the manifests; -### Use of `bump-minor-pre-major` and `bump-patch-for-minor-pre-major` +#### Use of `bump-minor-pre-major` and `bump-patch-for-minor-pre-major` Since the operator is still pre `v1.0.0` we are leveraging `bump-minor-pre-major` and `bump-patch-for-minor-pre-major` so that merging "feat", "fix", and "deps" commits will only bump a patch version and merging "feat!" and "fix!" will bump the minor version. As of writing, the operator release-please will only act on merges to `main`. This means that we can support the following release scenarios: + - Case 1: Release a patch version of v0.Y.x+1 with the diff from v0.Y.x. This is only supported until a breaking feature gets merged to `main`. - Case 2: Release a new minor version v0.Y+1.0 with the diff from v0.Y.x -### Use of `draft` +#### Use of `draft` Since the operator shares the same repo with Loki, we want to make sure that, when we create a release of the operator we don't that release to `latest`, otherwise it would look like the latest release from the operator was Loki's latest release. Unfortunately, release-please doesn't provide a way to disable this, so instead we enable `draft`. `draft` makes it so releases created by release-please are only created in draft. We then use a step that will publish the release without setting it to the latest. -### Preventing merging the release-please PR without updating the manifests +#### Preventing merging the release-please PR without updating the manifests Since step 1. is currently not automated and disconnected from release-please we have put in place a workflow in `.github/workflows/operator-check-prepare-release-commit.yml` that runs on release-please PRs. This workflow is responsible for making sure that in master exists a commit with the message `chore(operator): prepare community release v$VERSION`. Once we automate step 1. we should be able to remove this workflow. -## Publish release to operatorhubs +### Publish release to operatorhubs To publish a community release of Loki Operator to the community hubs we leverage the workflow in `.github/workflows/operator-publish-operator-hub.yml` this workflow is set to trigger on tag creation that matches `operator/`. This workflow will then use a workflow `.github/workflows/operator-reusable-hub-release.yml` that's responsible for: + - Creating on the folder `operators/loki-operator/` a new folder with the manifests for the new version; - Adding the ocp supported version annotation to the `metadata.yaml` file only in the OpenShift community repo; - Creating a PR for the appropriate community repo. -# Releasing +## Releasing -1. Create a PR to bump the version (i.e https://github.com/grafana/loki/pull/12246), be careful with the commit message; -2. Re-triggering the action `operator-publish-operator-hub` on the release-please PR; -3. Merging the release-please PR (i.e TBD ); +1. Create a PR to bump the version (i.e [v0.6.1 preparation PR](https://github.com/grafana/loki/pull/13105)), be careful with the commit message; +2. Re-trigger the action `operator-publish-operator-hub` on the release-please PR; +3. Merge the release-please PR (i.e [v0.6.1 release PR](https://github.com/grafana/loki/pull/12593) ); 4. Grafana bot will automatically open a PRs to [k8s-operatorhub/community-operators](https://github.com/k8s-operatorhub/community-operators) and [redhat-openshift-ecosystem/community-operators-prod](https://github.com/redhat-openshift-ecosystem/community-operators-prod); - diff --git a/operator/release-please-config.json b/operator/release-please-config.json index 18f4af8125f5c..f5566a75e52d2 100644 --- a/operator/release-please-config.json +++ b/operator/release-please-config.json @@ -1,5 +1,4 @@ { - "bootstrap-sha": "d4353fa63d9283a941b10b6c90537901e557a9f1", "bump-minor-pre-major": true, "bump-patch-for-minor-pre-major": true, "include-component-in-tag": true,