Releasing
Creating a release PR
This project uses release-please to automate changelog updates per release. Due to security restrictions1 in the
nutanix-cloud-native
GitHub organization, the release process is a little more complex than just using the
release-please-action.
When a release has been cut, a new release PR can be created manually using the release-please
CLI locally. This needs
to be run by someone with write permissions to the repository.
The new release PR can be only created against main
or release/*
branch.
Ensure to checkout main
or release/*
branch locally.
Create the release-please
branch and PR from main
or release/*
branch:
make release-please
This will create the branch and release PR. From this point on until a release is ready, the release-please-action
will keep the PR up to date (GHA workflows are only not allowed to create the original PR, they can keep the PR up to
date).
Cutting a release
When a release is ready, the commits in the release PR created above will need to be signed (again, this is a security requirement). To do this, check out the PR branch locally:
gh pr checkout <RELEASE_PR_NUMBER>
Sign the previous commit:
git commit --gpg-sign --amend --no-edit
If you are releasing a new minor release, then update the metadata.yaml
s so that the upcoming release version is used
for e.g. local development and e2e tests:
Add the new release to the root level
metadata.yaml
release series.Add the new release to the e2e configuration
test/e2e/data/shared/v1beta1-caren/metadata.yaml
release series.Add the next release to the e2e configuration
test/e2e/data/shared/v1beta1-caren/metadata.yaml
(e.g. if releasev0.6.0
then add release series forv0.7
).Update the
caren
provider configuration intest/e2e/config/caren.yaml
:- The first reference should be the most recent successful patch release of the previous minor version. For example, if you releasing v0.22, reference the most recent successful patch release of v0.21.
- The second reference should be the 99th patch version of the minor version being released. For example, if you are releasing v0.22, the reference should be v0.22.99.
Commit the changed files:
git add metadata.yaml test/e2e/data/shared/v1beta1-caren/metadata.yaml test/e2e/config/caren.yaml git commit --gpg-sign -m 'fixup! release: Update metadata for release'
And force push:
git push --force-with-lease
The PR will then need the standard 2 reviewers and will then be auto-merged, triggering the release jobs to run and push relevant artifacts and images.
Specifically, GitHub Actions workflows are not allowed to create or approve PRs due to a potential security flaw. See this blog post for more details, as well as the Security Hardening for GitHub Actions docs. ↩︎
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.