release: Keep it draft until all artifacts have been published

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>
This commit is contained in:
Greg Kurz
2024-03-20 17:09:19 +01:00
parent e9e94d2dbd
commit 5009fabde4
3 changed files with 39 additions and 2 deletions

View File

@@ -174,3 +174,16 @@ jobs:
./tools/packaging/release/release.sh upload-libseccomp-tarball ./tools/packaging/release/release.sh upload-libseccomp-tarball
env: env:
GH_TOKEN: ${{ github.token }} GH_TOKEN: ${{ github.token }}
publish-release:
needs: [ build-and-push-assets-amd64, build-and-push-assets-arm64, build-and-push-assets-s390x, build-and-push-assets-ppc64le, publish-multi-arch-images, upload-multi-arch-static-tarball, upload-versions-yaml, upload-cargo-vendored-tarball, upload-libseccomp-tarball ]
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Publish a release
run: |
./tools/packaging/release/release.sh publish-release
env:
GH_TOKEN: ${{ github.token }}

View File

@@ -21,7 +21,9 @@ release artifacts.
The action is manually triggered and is responsible for generating a new The action is manually triggered and is responsible for generating a new
release (including a new tag), pushing those to the release (including a new tag), pushing those to the
`kata-containers/kata-containers` repository. `kata-containers/kata-containers` repository. The new release is initially
created as a draft. It is promoted to an official release when the whole
workflow has completed successfully.
Check the [actions status Check the [actions status
page](https://github.com/kata-containers/kata-containers/actions) to verify all page](https://github.com/kata-containers/kata-containers/actions) to verify all
@@ -29,6 +31,13 @@ steps in the actions workflow have completed successfully. On success, a static
tarball containing Kata release artifacts will be uploaded to the [Release tarball containing Kata release artifacts will be uploaded to the [Release
page](https://github.com/kata-containers/kata-containers/releases). page](https://github.com/kata-containers/kata-containers/releases).
If the workflow fails because of some external environmental causes, e.g. network
timeout, simply re-run the failed jobs until they eventually succeed.
If for some reason you need to cancel the workflow or re-run it entirely, go first
to the [Release page](https://github.com/kata-containers/kata-containers/releases) and
delete the draft release from the previous run.
### Improve the release notes ### Improve the release notes
Release notes are auto-generated by the GitHub CLI tool used as part of our Release notes are auto-generated by the GitHub CLI tool used as part of our

View File

@@ -114,9 +114,23 @@ function _create_new_release()
_create_our_own_notes _create_our_own_notes
# This automatically creates the ${RELEASE_VERSION} tag in the repo
gh release create ${RELEASE_VERSION} \ gh release create ${RELEASE_VERSION} \
--generate-notes --title "Kata Containers ${RELEASE_VERSION}" \ --generate-notes --title "Kata Containers ${RELEASE_VERSION}" \
--notes-file "/tmp/our_notes_${RELEASE_VERSION}" --notes-file "/tmp/our_notes_${RELEASE_VERSION}" \
--draft
}
function _publish_release()
{
_check_required_env_var "GH_TOKEN"
RELEASE_VERSION="$(_release_version)"
# Make the release live on GitHub
gh release edit ${RELEASE_VERSION} \
--verify-tag \
--draft=false
} }
function _publish_multiarch_manifest() function _publish_multiarch_manifest()
@@ -203,6 +217,7 @@ function main()
upload-versions-yaml-file) _upload_versions_yaml_file ;; upload-versions-yaml-file) _upload_versions_yaml_file ;;
upload-vendored-code-tarball) _upload_vendored_code_tarball ;; upload-vendored-code-tarball) _upload_vendored_code_tarball ;;
upload-libseccomp-tarball) _upload_libseccomp_tarball ;; upload-libseccomp-tarball) _upload_libseccomp_tarball ;;
publish-release) _publish_release ;;
*) >&2 _die "Invalid argument" ;; *) >&2 _die "Invalid argument" ;;
esac esac
} }