knockknock10 commented on PR #6927: URL: https://github.com/apache/camel-k/pull/6927#issuecomment-6607158652
Thanks for asking. I went back to the full October 31 job log rather than relying only on the final error. The failure is caused by a change in the image format produced by the runner/build toolchain, not by the Camel K operator build failing. The evidence in [the failing job log](https://github.com/apache/camel-k/actions/runs/41151164827/job/124387759039#step:3) is: - The runner reports Docker Engine 29.9.2, Buildx 0.38.1, and `driver-type io.containerd.snapshotter.v1` (the containerd image store). - During each single-platform `docker buildx build --load`, BuildKit logs `exporting manifest`, then `exporting attestation manifest`, then `exporting manifest list`. This happens for both the amd64 and arm64 image builds. - Later, `images-push-all` first invokes `images-push` for the unqualified `2.12.0-nightly` tag. The old recipe pushes that tag and then runs `docker manifest create <tag> <same-tag>`. That source is already an image index/manifest list (the push returns the index digest), so classic `docker manifest create` rejects it with `is a manifest list`. The target exits before it reaches the architecture-specific tags. This is consistent with Docker's current behavior: the containerd image store supports image indices and attestations, and BuildKit adds minimal provenance attestations by default. Those attestations are represented in the image index: - [containerd image store](https://docs.docker.com/engine/storage/containerd) - [Build attestations](https://docs.docker.com/build/metadata/attestations/) The proposed Makefile change avoids feeding an existing index back into the classic manifest command. It pushes the per-architecture tags and assembles the final index with `docker buildx imagetools create`. Docker documents that this command accepts either manifest-list or single-platform sources and supports platform filtering: [imagetools create](https://docs.docker.com/reference/cli/docker/buildx/imagetools/create). I also checked the Buildx v0.38.1 implementation: its platform filter retains attestation descriptors linked to the selected platform, so this approach does not require disabling provenance ([source](https://github.com/docker/buildx/blob/v0.38.1/util/imagetools/create.go)). The ARM64 deployment timeout is a later symptom, not proven to have the same direct cause. The release publisher exits before completing the nightly tag; the ARM64 job then cannot be trusted to be testing the newly built image. The new ARM64 manifest pre-check and diagnostics are intended to distinguish a missing/wrong image from a pod startup problem. For validation, the dry-run only confirms Make expands the new recipe correctly; it does not prove a registry push. The decisive check is to run the publishing workflow with this change, inspect the final tags to confirm both `linux/amd64` and `linux/arm64` are present, and then run the ARM64 nightly job. The PR checks are still waiting for maintainer approval, so that end-to-end validation has not happened yet. I should have included this evidence and explanation in the original PR description. -- 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]
