You must have docker installed.
- A container image of the shared cluster-api-provider-metal3 manager
- A git tag
- A release on Github containing:
- A manifest file -
infrastructure-components.yaml
- A metadata file -
metadata.yaml
- A cluster template -
cluster-template.yaml
- A file containing an example of variables to set -
example_variables.rc
- A manifest file -
- The container image is found in the registry
quay.io/metal3-io
with an image name ofcluster-api-provider-metal3
and a tag that matches the release version. The image is automatically built once the release has been created.
There are two ways to do the release: automated (using GitHub workflow) or manual. The processes are as follows:
For version v0.x.y:
- Create an annotated tag
git tag -a -s v0.x.y -m v0.x.y
. - Push the tag to the GitHub repository
git push origin v0.x.y
NB:origin
should be the name of the remote pointing togithub.com/metal3-io/cluster-api-provider-metal3
. - Check the tag is existent in upstream repository. If it is, GitHub workflow should have automatically created a draft release for you. Please make sure the release notes are checked thoroughly before it is published.
- Run
make release-notes
to create the release notes . Copy the output and sort manually the items that need to be sorted. - Create an annotated tag
git tag -a v0.x.y -m v0.x.y
. To use your GPG signature when pushing the tag, usegit tag -s [...]
instead - Push the tag to the GitHub repository
git push origin v0.x.y
NB:origin
should be the name of the remote pointing togithub.com/metal3-io/cluster-api-provider-metal3
- Run
make release
to build artifacts (the image is automatically built by CI) - Create a release in GitHub
that contains the elements listed above that have been created in the
out
folder - Create a branch
release-0.x
for a minor release for backports and bug fixes. This is not needed for patch releases.
Releasing requires a particular set of permissions.
- Tag push access to the GitHub repository
- GitHub Release creation access
Multiple additional actions are required in the Metal3 project
For each minor or major release, two jobs need to be created :
- a main job that runs on a regular basis
- a PR verification job that is triggered by a keyword on a PR targeted for that release branch.
Metal3-dev-env variables need to be modified. After a major or minor release, the new minor version (that follows CAPI versioning) should point to main for CAPM3 and the released version should point to the release branch.
If you just created a release branch (i.e. minor version release), you should modify the image for CAPM3 deployment in this branch to be tagged with the branch name. The image will then follow the branch.
After releasing v0.x.y version of CAPM3, create an annotated tag with capm3
prefix + release version in Ironic-image Github
repository. NB: origin should be the name of the remote pointing to
Metal3 upstream repositories.
# Ironic
git clone https://github.com/metal3-io/ironic-image.git
cd ironic-image
git tag capm3-v0.x.y
git push origin capm3-v0.x.y
After this, Ironic container image will be created automatically with capm3-v0.x.y
tag in Quay.