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.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.

  2. Add the new release to the e2e configuration test/e2e/data/shared/v1beta1-caren/metadata.yaml release series.

  3. Add the next release to the e2e configuration test/e2e/data/shared/v1beta1-caren/metadata.yaml (e.g. if release v0.6.0 then add release series for v0.7).

  4. Update the caren provider configuration in test/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.
  5. 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.


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