[alekseinovikov]

Summary

Fixes paketo-buildpacks/builder-noble-java-tiny#344.

pack builder create --publish pushes an image per target under the version tag before it pushes the manifest list there (pkg/client/create_builder.go), and the registry can still return one of those right after the push. On builder-noble-java-tiny 0.0.200 (run 39973018505), crane tag <version> latest read :0.0.200 about 2 s after the manifest list was pushed and copied its linux/arm64 child (sha256:771c7c33…) to latest. Every amd64 build on the default Spring Boot / pack builder then failed with exec /cnb/lifecycle/creator: exec format error. 0.0.199 used the same runner image and tool versions and tagged the index correctly, so this is a race, not a tooling change.

Change

In builder/.github/workflows/push-image.yml, read the version tag with crane manifest until it lists every [[targets]] of builder.toml, then tag latest by the digest of exactly that manifest. Since crane manifest prints the raw bytes, sha256sum of its output is the digest, and the tag is never read twice. A builder with at most one target is tagged right away. If the version tag still doesn't list every target after 12 reads, 5 s apart, the job fails, and the existing failure job files an issue.

Alternatives considered:

• pack builder create --tag latest: pack applies additional tags only to the per-target images, not to the manifest list, so latest would always end up single-platform.
• --append-image-name-suffix: fixes the race at the source, but adds two -linux-<arch> tags to Docker Hub per release.

Testing

• actionlint (with shellcheck) passes.
• I ran the step against a stub crane that returns the real 0.0.200 manifests:
  • two stale arm64 reads, then the index: latest gets the index digest sha256:7c62dd7e…;
  • always arm64: the job fails after 12 reads;
  • a single-target builder.toml: tagged right away.
• The workflow itself only runs on a release, so I could not run it end to end.

🤖 Generated with Claude Code

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: alekseinovikov / name: alekseinovikov (ea92eba)

[pacostas]

I think this one should be 1, as even on single arch, we always have one target, the amd64. WDYT? It works, because the manifest.json will return 0, but is a little bit confusing. WDYT?

[alekseinovikov]

Right now TARGETS counts the entries of the manifest list, not platforms. A single-arch builder is published as a plain image without .manifests, so it’s 0 there, and that’s why I set EXPECTED_TARGETS to 0. I can switch both sides to count platforms instead: a plain image counts as 1 (if .manifests then (.manifests | length) else 1 end), and a builder.toml without targets expects 1. Then it reads naturally and still catches the race (a single-arch image gives 1 where 2 are expected). Want me to change it?

[pacostas]

Thank your for describing me the code.

Sorry, What do you mean

(a single-arch image gives 1 where 2 are expected)

Also, what do you think, what is your opinion about which one is more readable?

I like the platform idea, as at the end of the day is a docker issue, not buildpacks one.

[pacostas]

The targets also means in which platform the builder will run, so even in case of the target, to me, this one seems to be 1 too

[alekseinovikov]

During the race, the version tag points for a moment to the image of a single platform, like the arm64 one that ended up in latest. Counting platforms, that image gives 1 while builder.toml expects 2, so the step waits and reads again instead of tagging it. (a single-arch image gives 1 where 2 are expected)

Counting platforms reads better to me too: TARGETS and EXPECTED_TARGETS mean the same thing, so there’s no “0 means single-arch” trick.I’ll switch it to platforms and push the change.

[pacostas]

Can please also rename the variable name to be platforms instead of targets?

[pacostas]

Can you please also remove the comments?

[alekseinovikov]

Done