d339366a16
This is utterly counter intuitive, but if we change a file during the GitHub Action, the checkout done for the next workflow won't have that file updated, but rather the branch on its original state when the workflow was created. This makes us safe to always "calculate" the next release version from the VERSION file at the time the workflow was triggered. This requires us to have the release type exported for the whole workflow. Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Release information
Introduction
This directory contains information of the process and tools used for creating Kata Containers releases.
Create a Kata Containers release
See the release documentation.
Release tools
update-repository-version.sh
This script creates a GitHub pull request (a.k.a PR) to change the version in the Kata repository.
For more information on using the script, run the following:
$ ./update-repository-version.sh -h
Update Kata projects to a new version
To update project version for Kata Containers, use the following:
# Set to the required version
$ new_version="a.b.c"
$ make bump-kata-version NEW_VERSION="${new_version}"
The makefile target bump-kata-version creates a GitHub pull request in the
kata-containers repository. The pull request is tested by the Kata CI to ensure the
entire project is working prior to the release. Next, the PR is approved and
merged by Kata Containers members.
tag_repos.sh
After Kata Containers repository is updated with a new version, it needs to be tagged.
The tag_repos.sh script is used to create tags for the Kata Containers repository.
The script creates an annotated tag for the new release version.