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. Create the release-please
branch and PR:
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
with the new release (replacing the last minor release with the new minor release version) and the next minor release configuration (replacing thev0.x.99
configuration).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.