From 1f5ed27b993427ee1ec6ab0e2dadede98163b968 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= Date: Sat, 13 Jun 2026 14:15:30 +0200 Subject: [PATCH] release: tag per-arch images with the release version The per-arch kata-deploy/kata-monitor build jobs derived their image tag from $GITHUB_REF, which only resolves to the release version when the release workflow is dispatched from main. The multi-arch manifest step, however, always publishes using the release version, so dispatching the release workflow from any other branch tagged the per-arch images with the branch name and the manifest step failed with ": not found". Always tag the per-arch images with the release version so the build and manifest steps stay in sync regardless of the dispatch branch. This also subsumes the earlier "drop latest" tweak in these per-arch workflows. --- .github/workflows/release-amd64.yaml | 18 ++++++++---------- .github/workflows/release-arm64.yaml | 18 ++++++++---------- .github/workflows/release-kata-images.yaml | 10 ++++++---- .github/workflows/release-ppc64le.yaml | 18 ++++++++---------- .github/workflows/release-s390x.yaml | 18 ++++++++---------- 5 files changed, 38 insertions(+), 44 deletions(-) diff --git a/.github/workflows/release-amd64.yaml b/.github/workflows/release-amd64.yaml index 35b52b0043..f471954a85 100644 --- a/.github/workflows/release-amd64.yaml +++ b/.github/workflows/release-amd64.yaml @@ -69,16 +69,14 @@ jobs: env: TARGET_ARCH: ${{ inputs.target-arch }} run: | - # We need to do such trick here as the format of the $GITHUB_REF - # is "refs/tags/" - tag=$(echo "$GITHUB_REF" | cut -d/ -f3-) - if [ "${tag}" = "main" ]; then - tag=$(./tools/packaging/release/release.sh release-version) - # TESTING: drop "latest" so a run from this branch never moves it. - tags=("${tag}") - else - tags=("${tag}") - fi + # The multi-arch manifest is always published using the release + # version (see the publish-multiarch-manifest step), so the per-arch + # images must be tagged with the release version too -- regardless of + # the branch the release workflow was dispatched from. Otherwise a run + # from a testing branch would tag the images with the branch name and + # the manifest step would not be able to find them. + tag=$(./tools/packaging/release/release.sh release-version) + tags=("${tag}") for tag in "${tags[@]}"; do ./tools/packaging/kata-deploy/local-build/kata-deploy-build-and-upload-payload.sh \ "ghcr.io/kata-containers/kata-deploy" \ diff --git a/.github/workflows/release-arm64.yaml b/.github/workflows/release-arm64.yaml index 90d905d546..cebb790b79 100644 --- a/.github/workflows/release-arm64.yaml +++ b/.github/workflows/release-arm64.yaml @@ -69,16 +69,14 @@ jobs: env: TARGET_ARCH: ${{ inputs.target-arch }} run: | - # We need to do such trick here as the format of the $GITHUB_REF - # is "refs/tags/" - tag=$(echo "$GITHUB_REF" | cut -d/ -f3-) - if [ "${tag}" = "main" ]; then - tag=$(./tools/packaging/release/release.sh release-version) - # TESTING: drop "latest" so a run from this branch never moves it. - tags=("${tag}") - else - tags=("${tag}") - fi + # The multi-arch manifest is always published using the release + # version (see the publish-multiarch-manifest step), so the per-arch + # images must be tagged with the release version too -- regardless of + # the branch the release workflow was dispatched from. Otherwise a run + # from a testing branch would tag the images with the branch name and + # the manifest step would not be able to find them. + tag=$(./tools/packaging/release/release.sh release-version) + tags=("${tag}") for tag in "${tags[@]}"; do ./tools/packaging/kata-deploy/local-build/kata-deploy-build-and-upload-payload.sh \ "ghcr.io/kata-containers/kata-deploy" \ diff --git a/.github/workflows/release-kata-images.yaml b/.github/workflows/release-kata-images.yaml index 9108ae71cd..9dd2d05a3f 100644 --- a/.github/workflows/release-kata-images.yaml +++ b/.github/workflows/release-kata-images.yaml @@ -32,10 +32,12 @@ jobs: - name: Resolve tags id: tags run: | - tag=$(echo "${GITHUB_REF}" | cut -d/ -f3-) - if [ "${tag}" = "main" ]; then - tag=$(./tools/packaging/release/release.sh release-version) - fi + # The kata-monitor images are part of the release, so tag them with + # the release version regardless of the branch the release workflow + # was dispatched from. This keeps them in sync with the kata-deploy + # images and avoids a branch-name vs release-version mismatch between + # the per-arch images and the multi-arch manifest. + tag=$(./tools/packaging/release/release.sh release-version) # TESTING: never include the "latest" tag so a run from this branch # can never move the "latest" image tag. echo "tags=${tag}" >> "$GITHUB_OUTPUT" diff --git a/.github/workflows/release-ppc64le.yaml b/.github/workflows/release-ppc64le.yaml index 6440e22cc6..2725435945 100644 --- a/.github/workflows/release-ppc64le.yaml +++ b/.github/workflows/release-ppc64le.yaml @@ -66,16 +66,14 @@ jobs: env: TARGET_ARCH: ${{ inputs.target-arch }} run: | - # We need to do such trick here as the format of the $GITHUB_REF - # is "refs/tags/" - tag=$(echo "$GITHUB_REF" | cut -d/ -f3-) - if [ "${tag}" = "main" ]; then - tag=$(./tools/packaging/release/release.sh release-version) - # TESTING: drop "latest" so a run from this branch never moves it. - tags=("${tag}") - else - tags=("${tag}") - fi + # The multi-arch manifest is always published using the release + # version (see the publish-multiarch-manifest step), so the per-arch + # images must be tagged with the release version too -- regardless of + # the branch the release workflow was dispatched from. Otherwise a run + # from a testing branch would tag the images with the branch name and + # the manifest step would not be able to find them. + tag=$(./tools/packaging/release/release.sh release-version) + tags=("${tag}") for tag in "${tags[@]}"; do ./tools/packaging/kata-deploy/local-build/kata-deploy-build-and-upload-payload.sh \ "ghcr.io/kata-containers/kata-deploy" \ diff --git a/.github/workflows/release-s390x.yaml b/.github/workflows/release-s390x.yaml index ffb0961e72..0fa4b29fb2 100644 --- a/.github/workflows/release-s390x.yaml +++ b/.github/workflows/release-s390x.yaml @@ -67,16 +67,14 @@ jobs: env: TARGET_ARCH: ${{ inputs.target-arch }} run: | - # We need to do such trick here as the format of the $GITHUB_REF - # is "refs/tags/" - tag=$(echo "$GITHUB_REF" | cut -d/ -f3-) - if [ "${tag}" = "main" ]; then - tag=$(./tools/packaging/release/release.sh release-version) - # TESTING: drop "latest" so a run from this branch never moves it. - tags=("${tag}") - else - tags=("${tag}") - fi + # The multi-arch manifest is always published using the release + # version (see the publish-multiarch-manifest step), so the per-arch + # images must be tagged with the release version too -- regardless of + # the branch the release workflow was dispatched from. Otherwise a run + # from a testing branch would tag the images with the branch name and + # the manifest step would not be able to find them. + tag=$(./tools/packaging/release/release.sh release-version) + tags=("${tag}") for tag in "${tags[@]}"; do ./tools/packaging/kata-deploy/local-build/kata-deploy-build-and-upload-payload.sh \ "ghcr.io/kata-containers/kata-deploy" \