Minor cleanup.

Author: AlexeyKuznetsov-DD

.github/workflows/docker-tag.yml

@@ -49,6 +49,7 @@ jobs:
           # Collect all image references from COPY --from= and FROM directives
           mapfile -t ALL_REFS < <({
             sed -n 's/.*--from=\([^ ]*\).*/\1/p' Dockerfile
+            # Skip FROM options like `--platform` to capture the image reference
             awk '/^FROM/ {
               for (i = 2; i <= NF; i++) {
                 if ($i !~ /^--/) { print $i; break }

Dockerfile

@@ -102,13 +102,11 @@ RUN <<-EOT
 		/usr/lib/jvm/graalvm*/lib/installer
 EOT
 
-FROM --platform=linux/amd64 azul/zulu-openjdk:7 AS zulu7-amd64
-FROM --platform=linux/amd64 ibmjava:8-sdk AS ibm8-amd64
-
 FROM all-jdk-common AS all-jdk-arm64
 
+FROM --platform=linux/amd64 azul/zulu-openjdk:7 AS zulu7-amd64
+FROM --platform=linux/amd64 ibmjava:8-sdk AS ibm8-amd64
 FROM all-jdk-common AS all-jdk-amd64
-
 COPY --from=zulu7-amd64 /usr/lib/jvm/zulu7 /usr/lib/jvm/7
 COPY --from=ibm8-amd64 /opt/ibm/java /usr/lib/jvm/ibm8
 

README.md

@@ -11,9 +11,15 @@ Image variants are available on a per JDK basis:
 - The `zulu8`, `zulu11`, `oracle8`, `ibm8`, `semeru8`, `semeru11`, `semeru17`, `graalvm17`, `graalvm21`, and `graalvm25` variants each contain the base JDKs in addition to the specific JDK from their name.
 - The `latest` variant contains the base JDKs and all of the specific JDKs above.
 
-All variants are published as multi-arch manifests covering `linux/amd64` and `linux/arm64`, so the same tag (e.g. `base`, `zulu8`, `tip`) resolves to the correct image for the host architecture. The `7` and `ibm8` variants are amd64-only because the upstream JDK images are not available for arm64; `docker pull` for those tags on arm64 will fail.
-
-Images are tagged with `ci-` prefixes via the [Tag new images version](https://github.com/DataDog/dd-trace-java-docker-build/actions/workflows/docker-tag.yml) workflow, which runs quarterly on `master` and when manually triggered. A **48-hour cooldown** is enforced: the workflow verifies that all external upstream dependencies (Eclipse Temurin, Azul Zulu, IBM Semeru, GraalVM, etc.) referenced in the Dockerfile were built at least 48 hours ago before tagging. This ensures that upstream images have had sufficient time for vulnerability scans and community review before being CI use. On completion, it automatically triggers the [Update mirror digests for ci-* images](https://github.com/DataDog/dd-trace-java-docker-build/actions/workflows/update-mirror-digests.yml) workflow, which opens a PR in [DataDog/images](https://github.com/DataDog/images) updating the pinned `ci-*` mirror image digests. Once that PR is merged, `dd-trace-java` CI picks up the updated images from `registry.ddbuild.io`. Images are mirrored in `registry.ddbuild.io` to ensure they are signed before use in CI.
+All variants are published as multi-arch manifests covering `linux/amd64` and `linux/arm64`, so the same tag (e.g. `base`, `zulu8`, `tip`) resolves to the correct image for the host architecture.
+The `7` and `ibm8` variants are amd64-only because the upstream JDK images are not available for arm64;
+`docker pull` for those tags on arm64 will fail.
+
+Images are tagged with `ci-` prefixes via the [Tag new images version](https://github.com/DataDog/dd-trace-java-docker-build/actions/workflows/docker-tag.yml) workflow, which runs quarterly on `master` and when manually triggered.
+A **48-hour cooldown** is enforced: the workflow verifies that all external upstream dependencies (Eclipse Temurin, Azul Zulu, IBM Semeru, GraalVM, etc.) referenced in the Dockerfile were built at least 48 hours ago before tagging.
+This ensures that upstream images have had sufficient time for vulnerability scans and community review before being CI use. On completion, it automatically triggers the [Update mirror digests for ci-* images](https://github.com/DataDog/dd-trace-java-docker-build/actions/workflows/update-mirror-digests.yml) workflow,
+which opens a PR in [DataDog/images](https://github.com/DataDog/images) updating the pinned `ci-*` mirror image digests.
+Once that PR is merged, `dd-trace-java` CI picks up the updated images from `registry.ddbuild.io`. Images are mirrored in `registry.ddbuild.io` to ensure they are signed before use in CI.
 
 ## Development
 

build

@@ -78,9 +78,9 @@ function compute_metadata() {
     GIT_HEAD_REF="$(git show-ref --head --hash ^HEAD)"
 }
 
-# docker buildx wrapper for local single-platform builds. Uses --load so the
-# resulting image is available in the local docker daemon for testing. Uses
-# buildx (not plain `docker build`) so the buildx builder cache is shared with
+# docker buildx wrapper for local single-platform builds.
+# Uses --load so the resulting image is available in the local docker daemon for testing.
+# Uses buildx (not plain `docker build`) so the buildx builder cache is shared with
 # the later push-by-digest step.
 # See https://github.com/opencontainers/image-spec/blob/main/annotations.md for common labels
 # See https://docs.github.com/en/packages/learn-github-packages/connecting-a-repository-to-a-package
@@ -108,6 +108,7 @@ function docker_build() {
 # docker buildx wrapper that pushes the image by digest only (no tag) and writes
 # the resulting manifest digest to a metadata file. The merge step consumes
 # these files to assemble the multi-arch manifest list.
+# Avoid orphan attestation manifests from temporary digest-only pushes: `--provenance=false --sbom=false`.
 function buildx_push_by_digest() {
     local target="$1"
     local variant="$2"
@@ -122,6 +123,8 @@ function buildx_push_by_digest() {
         --label org.opencontainers.image.source=https://github.com/DataDog/dd-trace-java-docker-build \
         --label org.opencontainers.image.revision="$GIT_HEAD_REF" \
         --target "$target" \
+        --provenance=false \
+        --sbom=false \
         --output "type=image,name=${IMAGE_NAME},push-by-digest=true,name-canonical=true,push=true" \
         --metadata-file "${DIGESTS_DIR}/${ARCH}-${variant}.json" \
         "$@" \