Skip to content

Latest commit

 

History

History
51 lines (39 loc) · 2.42 KB

RELEASE.md

File metadata and controls

51 lines (39 loc) · 2.42 KB
Raw

Release process

The release process for CNAO consist of a pair of manual steps:

  1. Create release PR with github action Create Version PR, it has a pair of fields: versionLevel and baseBranch. versionLevel is the semVer version part to bump to and baseBranch is the branch to release from. To run it:
    • From the gh UI passing the versionLevel or baseBranch
    • With the gh cli like gh workflow run prepare-version.yaml -s versionLevel=... -s baseBranch=...
  2. Merge the version PR when continous integration is fine.

After the version PR is merged a prow job will release-cluster-network-addons-operator call the make release target that to do the following:

  1. Tag the code the version from the version PR.
  2. Generate release notes from the PRs release-notes field at description and the template
  3. Push containers to quay.io.
  4. Create a new github release and upload the artifacts.

Release notes handling

The release notes are generated using the kubernetes release-notes. The tool scan all the PRs between the version to release and the previous one and look for the following block on the PR description:

```release-note
Set default placement to os/linux nodes.
```

To categorize the change use the prow command /kind with the category you want /kind bug, /kind enhancement, etc... the kinds understood by the tool are listed here.

Sometime is needed to add some notes related actions to be done before or after an upgrade for that adding the "action requiered" string inside the relase-note block will add that line to the Urgent Upgrade Notes section on the release, like in the example

```release-note
Set default placement to os/linux nodes.
[action required]: Be sure that the nodes are linux
```

More information at k8s release notes workflow.