sadpandajoe commented on code in PR #45755:
URL: https://github.com/apache/superset/pull/45755#discussion_r4385492130
##########
.github/workflows/docker.yml:
##########
@@ -420,7 +606,9 @@ jobs:
# Release branch pushes and pull requests validate the build
# locally. Official release images are published only by the
# release workflow after the vote completes.
- eval "$(bash scripts/docker-build-plan.sh "$GITHUB_EVENT_NAME"
"$GITHUB_REF" "${GITHUB_REF_NAME:-}")"
+ # On master this builds linux/amd64 only; docker-build-arm64 built
+ # the other half natively and the step after this one merges them.
+ eval "$(bash scripts/docker-build-plan.sh "$GITHUB_EVENT_NAME"
"$GITHUB_REF" "${GITHUB_REF_NAME:-}" "$BUILD_PLATFORM")"
Review Comment:
This amd64-only push writes the public `master` and `<sha>` tags before the
manifest merge step runs, so those tags lose their arm64 entry until the merge
finishes. If the merge exhausts its retries or the run is cancelled, they stay
amd64-only, and re-running that commit is skipped by the master-tip guard once
a later commit lands. Could the amd64 image be pushed under a staging tag, with
the unsuffixed tags written only by the merge?
##########
.github/workflows/docker.yml:
##########
@@ -458,6 +646,56 @@ jobs:
sleep 30
done
+ # supersetbot tagged the linux/amd64 push above with the unsuffixed tags
+ # (<sha>, <short sha>, master, each with the preset chunk) and the
+ # linux/arm64 push in docker-build-arm64 with the same tags plus an
+ # `-arm` suffix. Fold each pair into one manifest list under the
+ # unsuffixed tag, which is what the single multi-platform build used
+ # to publish. The run-scoped GHA-* tags stay per platform (IMAGE_TAG
+ # carries a -arm64 suffix in the arm64 job) since nothing pulls them
+ # cross-platform.
+ - name: Publish the multi-platform manifest lists
+ if: >-
+ steps.publish_guard.outputs.publish == 'true' &&
+ github.event_name == 'push' && github.ref == 'refs/heads/master'
+ shell: bash
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ BUILD_PRESET: ${{ matrix.build_preset }}
+ run: |
+ set -euo pipefail
+ eval "$(bash scripts/docker-build-plan.sh "$GITHUB_EVENT_NAME"
"$GITHUB_REF" "${GITHUB_REF_NAME:-}" "$BUILD_PLATFORM")"
+ mapfile -t tags < <(
+ DOCKERHUB_TOKEN= supersetbot docker \
+ --preset "$BUILD_PRESET" \
+ --context "$BUILD_CONTEXT" \
+ --context-ref "$BUILD_CONTEXT_REF" \
+ --platform linux/amd64 \
+ --dry-run |
+ grep -oE -- '-t apache/superset:[^[:space:]\\]+' | cut -d' ' -f2
| sort -u
+ )
+ merged=0
+ for tag in "${tags[@]}"; do
+ case "$tag" in *:GHA-*) continue ;; esac
+ for attempt in 1 2 3; do
+ if docker buildx imagetools create -t "$tag" "$tag"
"${tag}-arm"; then
Review Comment:
Agreed—`master-arm` and its siblings are shared across commits and the arm64
job sits in its own concurrency group, so a newer commit's arm64 push can land
between this run's publish guard and the merge, leaving `master` with this
commit's amd64 image and the newer commit's arm64 image. Could the merge source
the per-commit `<sha>-arm` tags (or digests captured from the arm64 job)
instead?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
