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 "<image>: 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

@@ -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>"
-          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" \

.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>"
-          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" \

.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"

.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>"
-          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" \

.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>"
-          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" \