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

Build ci-fleet-publish plugin image #14

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

A versioned Woodpecker plugin image (git.oleks.space/oleks/ci-fleet-publish) encapsulating: arch banner, resolv.conf/nix.conf shims, nixos-ci-entrypoint, attic watch-store lifecycle with clean shutdown, and a settings-driven run command. Built and pushed by ci-scripts' own CI, semver tagged, repos pin major (:1).

See Spec/Modern-CI-Target for requirements.

A versioned Woodpecker plugin image (git.oleks.space/oleks/ci-fleet-publish) encapsulating: arch banner, resolv.conf/nix.conf shims, nixos-ci-entrypoint, attic watch-store lifecycle with clean shutdown, and a settings-driven run command. Built and pushed by ci-scripts' own CI, semver tagged, repos pin major (`:1`). 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:40 +03:00
repo-worker commented 2026-07-05 22:52:58 +03:00
Collaborator
Copy Link
Copy Source

Closing. The ci-fleet-publish plugin image is built, published, and pullable multi-arch.

Code (main):

  • entrypoint.sh (63f17f1, 6bd25f6, a04c5ae) — plugin entrypoint: arch banner, resolv.conf/nix.conf shims, attic login+watch-store lifecycle with explicit non-masking shutdown (no || true), delegates to nixos-ci-entrypoint for the publish flow.
  • Dockerfile — FROM git.oleks.space/oleks/nix-ci:latest, bakes in the entrypoint.
  • ci/local.sh — dev-parity build script (same script CI and a developer run).
  • .woodpecker/build-amd64.yaml + build-arm64.yaml + manifest.yaml (6bd25f6) — hand-authored per-arch pipeline files (see deviation note below), tag-triggered, build+push+manifest.

Verification:

  • git.oleks.space/oleks/ci-fleet-publish:v1.0.3 (also :v1, :latest) is a proper 2-member manifest list (linux/amd64 + linux/arm64, both plain manifest.v2 — not nested lists). Confirmed via docker buildx imagetools inspect and a real docker pull + docker run of the entrypoint (publish flow ran end-to-end against the real registry image).
  • shellcheck clean at default severity.
  • Multiple flows smoke-tested with fake attic/docker/nixos-ci-entrypoint binaries before ever touching CI.

Deviations from the wiki spec (Spec/Fleet Publish Plugin System, updated to match):

  1. Split the single buildx-multiarch flow value into explicit buildx-build / buildx-manifest — one flow value can't distinguish "build my arch's tag" from "consolidate the manifest" (two different Woodpecker steps, same image).
  2. This repo's own self-build pipeline is hand-authored (build-amd64.yaml/build-arm64.yaml) rather than generated via the shared generator's matrix kind — a Woodpecker scheduler issue on this cluster left the matrix's ${ARCH}-templated labels: unresolved at label-matching time for a stretch of debugging (later attributed mostly to unrelated infra: an unregistered webhook, fleet capacity, and the 2026-07-05 HeatWave/JuiceFS-CSI outage saga), and hardcoding sidesteps that risk entirely for this pipeline. Worth an audit of whether the shared generator's matrix kind is affected elsewhere.
  3. Found and fixed a real bug during the outage-recovery debugging: BuildKit ≥0.11 attaches provenance/SBOM attestations by default, which pushes even a single-platform buildx build as a manifest-list rather than a plain image manifest — broke docker manifest create downstream. Fixed with --provenance=false --sbom=false (commit 63f17f1).

Known follow-up (not blocking, noted for the migration wave): ci/local.sh's major tag comes out as v1 (from ${VERSION%%.*} on v1.0.3), while the wiki's thin-pipeline example shows repos pinning :1 (no v-prefix). Needs reconciling — either strip the v in the major-tag computation, or update the docs — during the #16/#17 migration wave.

v1.0.3's build/manifest run also happened to be a live real-world test of the #9 resilience logic (an earlier v1.0.2 run correctly published an arm64-only manifest when amd64 was blocked by unrelated registry data loss, then re-ran clean once that was fixed).

Closing. The `ci-fleet-publish` plugin image is built, published, and pullable multi-arch. **Code (main):** - `entrypoint.sh` (63f17f1, 6bd25f6, a04c5ae) — plugin entrypoint: arch banner, resolv.conf/nix.conf shims, attic login+watch-store lifecycle with explicit non-masking shutdown (no `|| true`), delegates to `nixos-ci-entrypoint` for the `publish` flow. - `Dockerfile` — `FROM git.oleks.space/oleks/nix-ci:latest`, bakes in the entrypoint. - `ci/local.sh` — dev-parity build script (same script CI and a developer run). - `.woodpecker/build-amd64.yaml` + `build-arm64.yaml` + `manifest.yaml` (6bd25f6) — hand-authored per-arch pipeline files (see deviation note below), tag-triggered, build+push+manifest. **Verification:** - `git.oleks.space/oleks/ci-fleet-publish:v1.0.3` (also `:v1`, `:latest`) is a proper 2-member manifest list (`linux/amd64` + `linux/arm64`, both plain `manifest.v2` — not nested lists). Confirmed via `docker buildx imagetools inspect` and a real `docker pull` + `docker run` of the entrypoint (publish flow ran end-to-end against the real registry image). - shellcheck clean at default severity. - Multiple flows smoke-tested with fake attic/docker/nixos-ci-entrypoint binaries before ever touching CI. **Deviations from the wiki spec (Spec/Fleet Publish Plugin System, updated to match):** 1. Split the single `buildx-multiarch` flow value into explicit `buildx-build` / `buildx-manifest` — one flow value can't distinguish "build my arch's tag" from "consolidate the manifest" (two different Woodpecker steps, same image). 2. This repo's own self-build pipeline is hand-authored (`build-amd64.yaml`/`build-arm64.yaml`) rather than generated via the shared generator's `matrix` kind — a Woodpecker scheduler issue on this cluster left the matrix's `${ARCH}`-templated `labels:` unresolved at label-matching time for a stretch of debugging (later attributed mostly to unrelated infra: an unregistered webhook, fleet capacity, and the 2026-07-05 HeatWave/JuiceFS-CSI outage saga), and hardcoding sidesteps that risk entirely for this pipeline. Worth an audit of whether the shared generator's matrix kind is affected elsewhere. 3. Found and fixed a real bug during the outage-recovery debugging: BuildKit ≥0.11 attaches provenance/SBOM attestations by default, which pushes even a single-platform `buildx build` as a manifest-list rather than a plain image manifest — broke `docker manifest create` downstream. Fixed with `--provenance=false --sbom=false` (commit 63f17f1). **Known follow-up (not blocking, noted for the migration wave):** `ci/local.sh`'s major tag comes out as `v1` (from `${VERSION%%.*}` on `v1.0.3`), while the wiki's thin-pipeline example shows repos pinning `:1` (no v-prefix). Needs reconciling — either strip the `v` in the major-tag computation, or update the docs — during the #16/#17 migration wave. v1.0.3's build/manifest run also happened to be a live real-world test of the #9 resilience logic (an earlier v1.0.2 run correctly published an arm64-only manifest when amd64 was blocked by unrelated registry data loss, then re-ran clean once that was fixed).
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#14
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?