feat(docker-promote): tag to promote is expected to be an artifact produced by CI workflow

Author: jbern0rd

.github/workflows/docker-promote.yml

@@ -26,10 +26,6 @@ on:
         description: "Registry the image lives in"
         type: string
         default: "docker.io"
-      source-tag-prefix:
-        description: "Prefix of the tag the CI tags production images with, before the short commit sha (e.g. `dev-`)"
-        type: string
-        default: "dev-"
       security-scan:
         description: "Enable Trivy Security Scan"
         type: boolean
@@ -61,7 +57,6 @@ jobs:
       CI_WORKFLOW: ${{ inputs.ci-workflow }}
       IMAGE: ${{ inputs.image-name }}
       REGISTRY: ${{ inputs.registry }}
-      SOURCE_TAG_PREFIX: ${{ inputs.source-tag-prefix }}
 
     steps:
       - name: Checkout
@@ -123,12 +118,10 @@ jobs:
 
           echo "✅ Tag $TAG matches $component version $declared"
 
-          # The CI tags images built from a production branch as
-          # <source-tag-prefix><short sha>, and the release tag points at that commit.
           echo "version=$version" | tee -a "$GITHUB_OUTPUT"
-          echo "source_tag=${SOURCE_TAG_PREFIX}$(echo "$GITHUB_SHA" | cut -c1-8)" | tee -a "$GITHUB_OUTPUT"
 
       - name: Wait for the CI run that built this commit
+        id: wait
         env:
           GH_TOKEN: ${{ github.token }}
         run: |
@@ -137,15 +130,18 @@ jobs:
           # being promoted. So the image is normally still missing when this job starts.
           for _ in $(seq 1 60); do
             run=$(gh run list --commit "$GITHUB_SHA" --workflow "$CI_WORKFLOW" --limit 1 \
-                    --json status,conclusion \
-                    --jq '.[] | "\(.status) \(.conclusion)"' 2>/dev/null || true)
+                    --json status,conclusion,databaseId \
+                    --jq '.[] | "\(.status) \(.conclusion) \(.databaseId)"' 2>/dev/null || true)
             status=${run%% *}
-            conclusion=${run##* }
+            rest=${run#* }
+            conclusion=${rest%% *}
+            run_id=${rest##* }
 
             case "$status" in
               completed)
                 if [ "$conclusion" = "success" ]; then
                   echo "✅ CI succeeded for $GITHUB_SHA"
+                  echo "run_id=$run_id" >> "$GITHUB_OUTPUT"
                   exit 0
                 fi
                 echo "❌ CI for $GITHUB_SHA concluded '$conclusion'; refusing to release"
@@ -164,6 +160,28 @@ jobs:
           echo "❌ Timed out after 30 minutes waiting for the CI run on $GITHUB_SHA"
           exit 1
 
+      - name: Download the image tag CI built for this commit
+        id: ci-tag
+        continue-on-error: true
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: docker-image-tag
+          path: ci-image-tag
+          run-id: ${{ steps.wait.outputs.run_id }}
+          github-token: ${{ github.token }}
+
+      - name: Resolve the source tag to promote
+        id: source-tag
+        run: |
+          if [ ! -f "ci-image-tag/image-tag.txt" ]; then
+            echo "❌ CI run did not publish the docker-image-tag artifact; cannot determine the image to promote"
+            echo "   The CI workflow ($CI_WORKFLOW) must upload a 'docker-image-tag' artifact containing the tag it pushed"
+            exit 1
+          fi
+          source_tag=$(cat "ci-image-tag/image-tag.txt")
+          echo "✅ CI recorded image tag $source_tag"
+          echo "source_tag=$source_tag" | tee -a "$GITHUB_OUTPUT"
+
       - name: Login to Docker Registry
         uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
         with:
@@ -178,7 +196,7 @@ jobs:
       - name: Resolve the digest CI built for this commit
         id: tested
         env:
-          SOURCE_TAG: ${{ steps.check.outputs.source_tag }}
+          SOURCE_TAG: ${{ steps.source-tag.outputs.source_tag }}
         run: |
           digest=$(docker buildx imagetools inspect "$IMAGE:$SOURCE_TAG" \
                      --format '{{.Manifest.Digest}}')
@@ -206,7 +224,7 @@ jobs:
 
       - name: Promote the tested image to the release tag
         env:
-          SOURCE_TAG: ${{ steps.check.outputs.source_tag }}
+          SOURCE_TAG: ${{ steps.source-tag.outputs.source_tag }}
           VERSION: ${{ steps.check.outputs.version }}
           DIGEST: ${{ steps.tested.outputs.digest }}
         run: |
@@ -231,7 +249,7 @@ jobs:
 
       - name: Summarise the release
         env:
-          SOURCE_TAG: ${{ steps.check.outputs.source_tag }}
+          SOURCE_TAG: ${{ steps.source-tag.outputs.source_tag }}
           VERSION: ${{ steps.check.outputs.version }}
           DIGEST: ${{ steps.tested.outputs.digest }}
         run: |

docker-promote/README.md

@@ -13,6 +13,7 @@ The calling workflow must trigger promotion from a release tag such as `vX.Y.Z`,
 
 - Validates that the release tag matches the version release-please recorded for the component
 - Waits for the CI workflow run for the tagged commit to complete successfully
+- Reuses the exact image tag CI recorded for the commit from the `docker-image-tag` artifact, and fails if the CI run did not publish one
 - Resolves the source image digest before promotion
 - Optionally re-scans the tested digest with Trivy
 - Copies the tested manifest to the release tag
@@ -26,7 +27,6 @@ The calling workflow must trigger promotion from a release tag such as `vX.Y.Z`,
 | `image-name` | Fully qualified OCI image name, without a tag | Yes | - |
 | `registry` | Registry hosting the image | No | `"docker.io"` |
 | `security-scan` | Enable the Trivy security scan before promotion | No | `true` |
-| `source-tag-prefix` | Prefix used by CI before the short commit SHA | No | `"dev-"` |
 | `trivy-version` | Trivy security scanner version | No | `"v0.71.0"` |
 
 ## Secrets
@@ -38,6 +38,8 @@ The calling workflow must trigger promotion from a release tag such as `vX.Y.Z`,
 
 ## Example Usage
 
+The source tag is not passed to this workflow: it is fetched from the `docker-image-tag` artifact that the CI run for the tagged commit uploaded (published by `docker-build` when `push: true`).
+
 ```yaml
 name: Release Docker Image
 
@@ -54,13 +56,17 @@ jobs:
     with:
       image-name: docker-regis.iex.ec/my-service
       registry: docker-regis.iex.ec
-      source-tag-prefix: dev-
       security-scan: false
     secrets:
       username: ${{ secrets.NEXUS_USERNAME }}
       password: ${{ secrets.NEXUS_PASSWORD }}
 ```
 
+The flow:
+
+1. **CI workflow** — builds the image, tags it (e.g. via a `prepare` job), pushes it, and uploads the applied tag as the `docker-image-tag` artifact.
+2. **Release workflow** — this one. On `vX.Y.Z` (or `component-vX.Y.Z`) it waits for that CI run, downloads the artifact to learn the exact tag CI pushed, and promotes that digest to the release tag.
+
 ## Notes
 
 - The release tag must point at a commit that is contained in `main`; the workflow refuses to release a tag created elsewhere.
@@ -69,7 +75,7 @@ jobs:
 - A tag without a component is matched against the `.` package, or against the single entry of the manifest.
 - A component is matched against a manifest key by full path or by its last segment, so `post-compute` resolves the key `post-compute` and a workspace path such as `crates/post-compute`.
 - The project must be released by release-please in manifest mode; `.release-please-manifest.json` is committed in the same PR as the version bump, so at the tagged commit it holds the version being released.
-- The source tag is formed as `<source-tag-prefix><short-commit-sha>`, for example `dev-1a2b3c4d`.
+- The source tag is the tag `docker-build` recorded in the `docker-image-tag` artifact of the CI run for the commit, so any CI tag scheme (`dev-<sha>`, `feature-<sha>`, `cid.<sha>.main`, …) is supported. Promotion fails with a clear error if the CI run did not publish the artifact.
 - Set `security-scan: false` to skip the promotion-time Trivy scan. The CI build should still perform its configured scan.
 - Keep `trivy-version` in sync with the version used by `docker-build` so a promotion finding reflects a vulnerability database update rather than a scanner change.
 - The registry credentials need read and write access because promotion creates the release tag.
@@ -81,6 +87,7 @@ jobs:
 - **No version recorded for the component** — the tag prefix is not a package in `.release-please-manifest.json`; check the `component` names in `release-please-config.json`.
 - **Tag version does not match the recorded version** — the tag is expected to be `v` or `<component>-v` followed by the version release-please released for that component.
 - **Timed out waiting for the CI run** — confirm that `ci-workflow` names the workflow that builds the image and that it has started for the tagged commit.
-- **Source image or digest cannot be resolved** — confirm that CI pushed `<image-name>:<source-tag-prefix><short-commit-sha>` to `registry`.
+- **CI did not publish the docker-image-tag artifact** — the CI workflow named by `ci-workflow` must build the image with a `docker-build` version that records and uploads the `docker-image-tag` artifact (`push: true`); promotion cannot infer the tag otherwise.
+- **Source image or digest cannot be resolved** — confirm that CI pushed `<image-name>:<source-tag>` to `registry`.
 - **Release tag does not point at the tested image** — the registry or buildx version may not support manifest promotion; keep the buildx setup step up to date.
 - **Trivy reports CRITICAL or HIGH vulnerabilities** — the promotion is stopped before the release tag is created; update the image and rerun the release.

docker-promote/workflow-sha256

@@ -1 +1 @@
-52180f32c4fc50c4c53b09128a7380cda91d1041f26182c169262862a824fb40
+3bf93c62fbac5336bec03e0ebff19b048acdec31a22ea9ce223cea2901d81540