oleks/ci-scripts
1
0
Fork 0
Code Issues 8 Pull Requests Actions Packages Projects Releases Wiki Activity

Multi-arch flow in the plugin (quartet shape) #15

New Issue
Closed
opened 2026-07-05 16:35:41 +03:00 by oleks · 1 comment
oleks commented 2026-07-05 16:35:41 +03:00
Owner
Copy Link
Copy Source

Extend the plugin (or a sibling image) with the buildx build→push→manifest flow, including the #9 resilience behavior: manifest step probes the registry for landed per-arch tags and creates a manifest from whatever succeeded.

See Spec/Modern-CI-Target for requirements.

Extend the plugin (or a sibling image) with the buildx build→push→manifest flow, including the #9 resilience behavior: manifest step probes the registry for landed per-arch tags and creates a manifest from whatever succeeded. See [Spec/Modern-CI-Target](wiki/Spec/Modern-CI-Target) for requirements.
oleks added this to the Modern CI Phase 2+3 milestone 2026-07-05 16:35:41 +03:00
repo-worker commented 2026-07-05 22:53:06 +03:00
Collaborator
Copy Link
Copy Source

Closing. The buildx multi-arch quartet flow is implemented, tested, and verified live.

Code (main, entrypoint.sh):

  • buildx_build_flow (PLUGIN_FLOW=buildx-build) — builds+pushes a single per-arch tag for the current node's arch, using PLUGIN_IMAGE_NAME, PLUGIN_TAG_SCHEME (default {version}-{arch}), PLUGIN_PLATFORMS-independent (one arch per matrix leg).
  • buildx_manifest_flow (PLUGIN_FLOW=buildx-manifest) — probes the registry (docker manifest inspect) for which of PLUGIN_PLATFORMS' per-arch tags actually landed, and creates+pushes a manifest (PLUGIN_DEST_TAGS, default {version},latest) from whatever exists. Per oleks/ci-scripts#9: fails only if zero arches landed, never skips consolidation on partial success.

Live verification of the #9 resilience path: during the 2026-07-05 outage-recovery saga, an actual CI run (v1.0.2) hit exactly the partial-success case for real — amd64 was blocked by unrelated registry data loss while arm64 succeeded — and buildx-manifest correctly published an arm64-only manifest (v1.0.2, v1, latest) instead of failing the whole pipeline. Confirmed via docker buildx imagetools inspect (1 member) and a real pull. Once the registry was restored, a clean re-run (v1.0.3) produced the intended 2-member manifest (linux/amd64 + linux/arm64).

Real bug found and fixed along the way: BuildKit ≥0.11's default provenance/SBOM attestations turned even single-platform pushes into manifest-lists, which docker manifest create refuses to reference as members. Fixed with --provenance=false --sbom=false in buildx_build_flow (commit 63f17f1). Verified locally with a throwaway registry before it ever hit CI, then confirmed against the real registry.

Deviation from spec (see #14 for the fuller writeup, and the updated Spec/Fleet Publish Plugin System wiki page): split the single buildx-multiarch flow value into buildx-build / buildx-manifest since one flow value can't express which of the two roles a given Woodpecker step is playing.

v1.0.3 pullable and inspected: 2 members, both plain manifest.v2 (not nested lists), linux/amd64 + linux/arm64.

Closing. The buildx multi-arch quartet flow is implemented, tested, and verified live. **Code (main, `entrypoint.sh`):** - `buildx_build_flow` (`PLUGIN_FLOW=buildx-build`) — builds+pushes a single per-arch tag for the current node's arch, using `PLUGIN_IMAGE_NAME`, `PLUGIN_TAG_SCHEME` (default `{version}-{arch}`), `PLUGIN_PLATFORMS`-independent (one arch per matrix leg). - `buildx_manifest_flow` (`PLUGIN_FLOW=buildx-manifest`) — probes the registry (`docker manifest inspect`) for which of `PLUGIN_PLATFORMS`' per-arch tags actually landed, and creates+pushes a manifest (`PLUGIN_DEST_TAGS`, default `{version},latest`) from whatever exists. Per oleks/ci-scripts#9: fails only if **zero** arches landed, never skips consolidation on partial success. **Live verification of the #9 resilience path:** during the 2026-07-05 outage-recovery saga, an actual CI run (v1.0.2) hit exactly the partial-success case for real — amd64 was blocked by unrelated registry data loss while arm64 succeeded — and `buildx-manifest` correctly published an arm64-only manifest (`v1.0.2`, `v1`, `latest`) instead of failing the whole pipeline. Confirmed via `docker buildx imagetools inspect` (1 member) and a real pull. Once the registry was restored, a clean re-run (v1.0.3) produced the intended 2-member manifest (`linux/amd64` + `linux/arm64`). **Real bug found and fixed along the way:** BuildKit ≥0.11's default provenance/SBOM attestations turned even single-platform pushes into manifest-lists, which `docker manifest create` refuses to reference as members. Fixed with `--provenance=false --sbom=false` in `buildx_build_flow` (commit 63f17f1). Verified locally with a throwaway registry before it ever hit CI, then confirmed against the real registry. **Deviation from spec (see #14 for the fuller writeup, and the updated Spec/Fleet Publish Plugin System wiki page):** split the single `buildx-multiarch` flow value into `buildx-build` / `buildx-manifest` since one flow value can't express which of the two roles a given Woodpecker step is playing. v1.0.3 pullable and inspected: 2 members, both plain `manifest.v2` (not nested lists), `linux/amd64` + `linux/arm64`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Bug or defect (requires fix)
 epic:modern-ci
p1
No labels
Milestone
No items
No Milestone Modern CI Phase 2+3
Projects
Clear projects
No projects
Assignees
Clear assignees
repo-worker oleks
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: oleks/ci-scripts#15
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?