This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Contributing

1 - 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, the update the metadata.yamls so that the upcoming release version is used for e.g. local development and e2e tests:

  1. Add the new release to the root level metadata.yaml release series.

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.

  1. 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. ↩︎