mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-01-19 00:28:32 +00:00
The automated release workflow starts with the creation of the release in GitHub. This is followed by the build and upload of the various artifacts, which can be very long (like hours). During this period, the release appears to be fully available in https://github.com/kata-containers/kata-containers/ even though it lacks all the artifacts. This might be confusing for users or automation consuming the release. Create the release as draft and clear the draft flag when all jobs are done. This ensure that the release will only be tagged and made public when it is fully usable. If some job fails because of network timeout or any other transient error, the correct action is to restart the failed jobs until they eventually all succeed. This is by far the quicker path to complete the release process. If the workflow is *canceled* for some reason, the draft release is left behind. A new run of the workflow will create a brand new draft release with the same name (not an issue with GitHub). The draft release from the previous run should be manually deleted. This step won't be automated as it looks safer to leave the decision to a human. [1] https://github.com/kata-containers/kata-containers/releases Fixes #9064 - part VI Signed-off-by: Greg Kurz <groug@kaod.org>
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
release.sh
This script is used by GitHub actions in the
release
file from the kata-containers/kata-containers repository to handle the various steps of
the release process.
generate_vendor.sh
This script is used by release.sh to generate a tarball with all the cargo vendored code.