Skip to content

Commit

Permalink
chore: add support for Release Candidates (cloudnative-pg#4900)
Browse files Browse the repository at this point in the history
This PR enhances the release process to add support for release
candidate (RC) versions.
Initially, only the YAML manifest installation method is going to be
supported.

Closes cloudnative-pg#4778

Signed-off-by: Niccolò Fei <[email protected]>
Signed-off-by: Gabriele Bartolini <[email protected]>
Signed-off-by: Francesco Canovai <[email protected]>
Co-authored-by: Gabriele Bartolini <[email protected]>
Co-authored-by: Marco Nenciarini <[email protected]>
Co-authored-by: Francesco Canovai <[email protected]>
  • Loading branch information
4 people authored Jul 4, 2024
1 parent 0aa5ff2 commit e6b16b6
Show file tree
Hide file tree
Showing 6 changed files with 111 additions and 41 deletions.
10 changes: 7 additions & 3 deletions .github/workflows/release-pr.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,13 @@ jobs:
-
name: Get tag
run: |
TAG=${GITHUB_REF##*/}
DEST=$(echo ${TAG#v} | awk -F '[.]' '{print "release-"$1"."$2}')
echo "TAG=${TAG#v}" >> $GITHUB_ENV
TAG=${GITHUB_REF##*/v}
if [[ "${TAG}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
DEST=$(echo ${TAG} | awk -F '[.]' '{print "release-"$1"."$2}')
else
DEST="main"
fi
echo "TAG=${TAG}" >> $GITHUB_ENV
echo "DEST=${DEST}" >> $GITHUB_ENV
-
name: Pull Request
Expand Down
31 changes: 22 additions & 9 deletions .github/workflows/release-publish.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,11 +17,12 @@ permissions:

jobs:

check-branch:
check-version:
name: Evaluate release tag
runs-on: ubuntu-22.04
outputs:
is_latest: ${{ env.IS_LATEST }}
is_stable: ${{ env.IS_STABLE }}
steps:
-
name: Checkout
Expand All @@ -30,7 +31,7 @@ jobs:
# To identify the commit we need the history and all the tags.
fetch-depth: 0
-
name: Check release branch
name: Check release version
run: |
tag="${GITHUB_REF#refs/tags/v}"
latest_release_branch=$(git branch -rl 'origin/release-*' | sort -r | head -n1 | sed -e 's/^.*\(release-.*\)/\1/')
Expand All @@ -39,13 +40,18 @@ jobs:
if [[ "$latest_release_branch" == "$current_release_branch" ]]; then
is_latest="true"
fi
is_stable="false"
if [[ "$tag" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
is_stable="true"
fi
echo "IS_LATEST=${is_latest}" >> $GITHUB_ENV
echo "IS_STABLE=${is_stable}" >> $GITHUB_ENV
release:
name: Create Github release
runs-on: ubuntu-22.04
needs:
- check-branch
- check-version
steps:
-
name: Checkout
Expand Down Expand Up @@ -74,15 +80,16 @@ jobs:
draft: false
name: v${{ env.TAG }}
files: releases/cnpg-${{ env.VERSION }}.yaml
make_latest: ${{ needs.check-branch.outputs.is_latest }}
make_latest: ${{ needs.check-version.outputs.is_latest == 'true' && needs.check-version.outputs.is_stable == 'true' }}
prerelease: ${{ needs.check-version.outputs.is_stable == 'false' }}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

release-binaries:
name: Build containers
runs-on: ubuntu-22.04
needs:
- check-branch
- check-version
outputs:
version: ${{ steps.build-meta.outputs.version }}
author_name: ${{ steps.build-meta.outputs.author_name }}
Expand Down Expand Up @@ -151,16 +158,22 @@ jobs:
GPG_FINGERPRINT: ${{ steps.import_gpg.outputs.fingerprint }}
-
name: Publish Krew
if: ${{ needs.check-branch.outputs.is_latest == 'true' }}
if: |
needs.check-version.outputs.is_latest == 'true' &&
needs.check-version.outputs.is_stable == 'true'
uses: rajatjindal/[email protected]
with:
krew_template_file: dist/krew/cnpg.yaml
-
name: Docker meta
id: docker-meta
uses: docker/metadata-action@v5
env:
IS_LATEST: ${{ needs.check-version.outputs.is_latest == 'true' && needs.check-version.outputs.is_stable == 'true' }}
with:
images: ${{ env.IMAGES }}
flavor: |
latest=${{ env.IS_LATEST }}
tags: |
type=semver,pattern={{version}}
-
Expand Down Expand Up @@ -245,12 +258,13 @@ jobs:
name: Create OLM bundle and catalog
runs-on: ubuntu-22.04
needs:
- check-branch
- check-version
- release-binaries
if: |
(always() && !cancelled()) &&
needs.release-binaries.result == 'success' &&
needs.check-branch.outputs.is_latest == 'true'
needs.check-version.outputs.is_latest == 'true' &&
needs.check-version.outputs.is_stable == 'true'
steps:
- name: Checkout code
uses: actions/checkout@v4
Expand Down Expand Up @@ -388,7 +402,6 @@ jobs:
- release-binaries
if: |
(always() && !cancelled()) &&
needs.release-binaries.result == 'success' &&
needs.olm-bundle.result == 'success' &&
github.repository_owner == 'cloudnative-pg'
env:
Expand Down
5 changes: 4 additions & 1 deletion .github/workflows/release-tag.yml
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,9 @@ on:
- closed
branches:
- release-*
- main
paths:
- 'pkg/versions/versions.go'

jobs:
tag:
Expand All @@ -21,6 +24,6 @@ jobs:
uses: christophebedard/[email protected]
with:
token: ${{ secrets.REPO_GHA_PAT }}
version_regex: '^Version tag to ([0-9]+\.[0-9]+\.[0-9]+)'
version_regex: '^Version tag to ([0-9]+\.[0-9]+\.[0-9]+(?:-[a-z][0-9a-z]*)?)'
version_tag_prefix: v
dry_run: false
30 changes: 26 additions & 4 deletions contribute/release_procedure.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ This section describes how to release a new set of supported versions of
CloudNativePG, which should be done by one of the project's maintainers.
It is a semi-automated process that requires human supervision.

You can only release from a release branch, that is a branch in the
Git repository called `release-X.Y`, e.g., `release-1.16`, which corresponds
to a minor release.
You can only release stable versions from a release branch, that is a branch
in the Git repository called `release-X.Y`, e.g., `release-1.16`, which
corresponds to a minor release.

The release procedure must be repeated for all the supported minor releases,
usually 3:
Expand Down Expand Up @@ -122,7 +122,7 @@ but in `release-1.17`, the file should stay in `release_notes/`.

**IMPORTANT:** The instructions in the previous sections should have been completed ahead
of this. I.e., all cherry-picks should be done, documents should be up-to-date,
and the release notes should have been merged in `main`.
and the release notes should have been merged in `main`.

A new release branch is created starting from the most updated commit in the
trunk by a maintainer:
Expand Down Expand Up @@ -237,3 +237,25 @@ and the Kubernetes ones are aligned with the supported release page.

Open the `.github/ISSUE_TEMPLATES/bug.yml` file and update it accordingly.

## Release candidate

It's possible to create a release candidate (RC) for a new upcoming
minor release.
Unlike stable releases, a release candidate will be released just for one
version, as such the release process doesn't have to be repeated for all
the supported release branches.

**IMPORTANT:** Release candidates should always be released from the
`main` branch. A release branch for a new minor should only be created
once we are releasing the first stable version. This is necessary to
ensure the newly created release branch is a descendant of the `main`
branch.

To release a RC you can follow the [Release steps](#release-steps) until
point 5, taking care to use a valid semantic version when running the first
step (e.g., `hack/release.sh 1.16.0-rc1`).
See [Semantic Versioning 2.0.0 - item 9](https://semver.org/#spec-item-9) to
check for valid release candidate identifiers.

**NOTE:** Release candidates can only be installed via the YAML manifest,
other installation methods such as Helm Chart or OLM are currently not supported.
50 changes: 32 additions & 18 deletions docs/src/supported_releases.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,43 +24,57 @@ Subsequent patch releases on a minor release contain backward-compatible changes
* [Support status of CloudNativePG releases](#support-status-of-cloudnativepg-releases)
* [What we mean by support](#what-we-mean-by-support)

## Support policy
## Support Policy

We produce new builds of CloudNativePG for each commit.
CloudNativePG produces new builds for each commit.

Approximately every two months, we build a minor release and run through several
additional tests as well as release qualification. We release patch versions
for issues found in supported minor releases.
Approximately every two months, we create a minor release that undergoes
several additional tests and a thorough release qualification process. We
release patch versions for issues found in supported minor releases.

The various types of releases represent a different product quality level and
level of assistance from the CloudNativePG community.
For details on the support provided by the community, see
[What we mean by support](#what-we-mean-by-support).
Before an official release, at least one Release Candidate (RC) is built for
testing. Additional release candidates may be issued if new bugs are
discovered. The Release Candidates are announced on the Slack channel to
encourage community testing before the final release. The maintainers provide
1-2 weeks for community testing, and if no objections are raised, the final
release is announced.

Different types of releases represent varying levels of product quality and
assistance from the CloudNativePG community. For details on the support
provided by the community, see [What we mean by support](#what-we-mean-by-support).

| Type | Support level | Quality and recommended Use |
|-------------------|-----------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
| Development Build | No support | Dangerous, might not be fully reliable. Useful to experiment with. |
| Development Build | No support | Dangerous, might not be fully reliable. Useful to experiment with. |
| Release Candidate | No support | Preview version: Not production-ready. Released for experimentation and testing. |
| Minor Release | Support provided until 3 months after the N+1 minor release (ex. 1.23 supported until 3 months after 1.24.0 is released)|
| Patch | Same as the corresponding minor release | Users are encouraged to adopt patch releases as soon as they are available for a given release. |
| Security Patch | Same as a patch, however, it doesn't contain any additional code other than the security fix from the previous patch | Given the nature of security fixes, users are **strongly** encouraged to adopt security patches after release. |
| Security Patch | Same as a patch, however, it doesn't contain any additional code other than the security fix from the previous patch | Given the nature of security fixes, users are **strongly** encouraged to adopt security patches after release. |

You can find available releases on the [releases page](https://github.com/cloudnative-pg/cloudnative-pg/releases).

You can find high-level more information for each minor and patch release in the [release notes](release_notes.md).
You can find high-level more information for each minor and patch release in
the [release notes](release_notes.md).

Sure, here’s an improved version of the naming scheme section:

## Naming scheme
## Naming Scheme

Our naming scheme is based on [Semantic Versioning 2.0.0](https://semver.org/)
as follows:
Our naming scheme follows [Semantic Versioning 2.0.0](https://semver.org/) and
is structured as follows:

```
<major>.<minor>.<patch>
```

Where `<minor>` is increased for each release, and `<patch>` counts the number of patches for the
current `<minor>` release. A patch is usually a small change relative to the `<minor>` release.
- `<minor>` is incremented for each release.
- `<patch>` counts the number of patches for the current `<minor>` release,
representing small changes relative to the `<minor>` release.

Release candidates are indicated by an additional `-<pre-release>` identifier
following the patch version, as specified in [Semantic Versioning 2.0.0 - item #9](https://semver.org/#spec-item-9).

Git tags for versions are prepended with `v`.
Git tags for versions are prefixed with `v`.

## Support status of CloudNativePG releases

Expand Down
26 changes: 20 additions & 6 deletions hack/release.sh
Original file line number Diff line number Diff line change
Expand Up @@ -68,14 +68,28 @@ require_clean_work_tree () {

require_clean_work_tree "release"

# Verify that you are in a release branch
if branch=$(git symbolic-ref --short -q HEAD) && [[ "$branch" == release-* ]]
then
# Verify that you are in a proper branch
# Releases can only be triggered from:
# - a release branch (for stable releases)
# - main (for release candidate only)
branch=$(git symbolic-ref --short -q HEAD)
case $branch in
release-*)
echo "Releasing ${release_version}"
else
echo >&2 "Release is not possible because you are not on a 'release-*' branch ($branch)"
;;
main)
if [[ "${release_version}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]
then
echo >&2 "Cannot release a stable version from 'main'"
exit 1
fi
echo "Releasing ${release_version}"
;;
*)
echo >&2 "Release is not possible because you are not on 'main' or a 'release-*' branch ($branch)"
exit 1
fi
;;
esac

make kustomize
KUSTOMIZE="${REPO_ROOT}/bin/kustomize"
Expand Down

0 comments on commit e6b16b6

Please sign in to comment.