ci-fleet-publish: buildx-build/buildx-manifest flows never authenticate to the registry before push #23

New Issue

2026-07-09T20:37:40+03:00

issuer-agent commented

2026-07-09 20:37:40 +03:00

Problem: entrypoint.sh's buildx_build_flow() and buildx_manifest_flow() functions call docker buildx build --push ... and docker manifest create/docker manifest push respectively, but neither function ever calls docker login or sets up any registry authentication. The REGISTRY_TOKEN is available as a plain env var (declared as a Woodpecker secret in rendered thin pipelines) but is never actually used.

Why this matters: I verified via Woodpecker v3.15.0's own source (pipeline/backend/kubernetes/secrets.go, pipeline/backend/docker/docker.go) that Woodpecker's built-in "registries" / AuthConfig mechanism only covers PULLING the step's own container image (e.g. pulling ci-fleet-publish:v1 itself) — it is never exposed inside the container for arbitrary docker commands to use for PUSHING to a registry. The base nix-ci image's flake.nix also has no baked-in docker credentials/config.json for registry push.

Consequence: Once xonsh-image (or any repo) is migrated to flow: buildx-build/flow: buildx-manifest, the docker buildx build --push and docker manifest push calls will fail with an authentication error against git.oleks.space. This is currently latent (not yet triggering failures) only because no repo has actually been migrated to these flows yet — xonsh-image's current pre-migration pipeline does its own explicit docker login inside ci/local.sh, which the buildx-build/buildx-manifest flows don't replicate.

Fix needed: Add an explicit docker login "$REGISTRY_HOST" -u <user> --password-stdin (or equivalent via REGISTRY_TOKEN) call at the start of both buildx_build_flow() and buildx_manifest_flow() in entrypoint.sh, mirroring the registry_login() pattern already used in xonsh-image/csi-s3's own ci/local.sh scripts. Use existing REGISTRY_HOST/REGISTRY_USER conventions (e.g., git.oleks.space, user oleks).

Scope note: This is separate from and does NOT block #21 (tag_strip_v) — that fix's v1.0.4 release can proceed independently. This new bug needs to land (likely as v1.0.5) before anyone attempts the xonsh-image canary migration under #17.

Related:

#17 (xonsh-image canary migration to buildx flows)
#21 (tag_strip_v fix)

**Problem**: `entrypoint.sh`'s `buildx_build_flow()` and `buildx_manifest_flow()` functions call `docker buildx build --push ...` and `docker manifest create`/`docker manifest push` respectively, but neither function ever calls `docker login` or sets up any registry authentication. The `REGISTRY_TOKEN` is available as a plain env var (declared as a Woodpecker secret in rendered thin pipelines) but is never actually used. **Why this matters**: I verified via Woodpecker v3.15.0's own source (`pipeline/backend/kubernetes/secrets.go`, `pipeline/backend/docker/docker.go`) that Woodpecker's built-in "registries" / AuthConfig mechanism only covers PULLING the step's own container image (e.g. pulling `ci-fleet-publish:v1` itself) — it is never exposed inside the container for arbitrary docker commands to use for PUSHING to a registry. The base `nix-ci` image's flake.nix also has no baked-in docker credentials/config.json for registry push. **Consequence**: Once xonsh-image (or any repo) is migrated to `flow: buildx-build`/`flow: buildx-manifest`, the `docker buildx build --push` and `docker manifest push` calls will fail with an authentication error against `git.oleks.space`. This is currently latent (not yet triggering failures) only because no repo has actually been migrated to these flows yet — xonsh-image's current pre-migration pipeline does its own explicit `docker login` inside `ci/local.sh`, which the buildx-build/buildx-manifest flows don't replicate. **Fix needed**: Add an explicit `docker login "$REGISTRY_HOST" -u <user> --password-stdin` (or equivalent via `REGISTRY_TOKEN`) call at the start of both `buildx_build_flow()` and `buildx_manifest_flow()` in entrypoint.sh, mirroring the `registry_login()` pattern already used in xonsh-image/csi-s3's own `ci/local.sh` scripts. Use existing REGISTRY_HOST/REGISTRY_USER conventions (e.g., `git.oleks.space`, user `oleks`). **Scope note**: This is separate from and does NOT block #21 (tag_strip_v) — that fix's v1.0.4 release can proceed independently. This new bug needs to land (likely as v1.0.5) before anyone attempts the xonsh-image canary migration under #17. **Related**: - #17 (xonsh-image canary migration to buildx flows) - #21 (tag_strip_v fix)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oleks/ci-scripts#23