unkin-agent 5977527348
ci/woodpecker/pr/build Pipeline was successful
Dockerfile: fully-qualify base image (buildah short-name TTY fix)
buildah (quay.io/buildah/stable) enforces short-name resolution and cannot
prompt without a TTY, so 'FROM woodpeckerci/plugin-docker-buildx:latest' errors.
Qualify as docker.io/... . Keep it on docker.io (public CA) deliberately: this
image is what bootstraps internal-CA trust, so pulling its own base through the
internal-CA artifactapi registry would reintroduce the x509 problem in-build.
2026-08-15 16:34:02 +10:00

plugin-docker-buildx

A drop-in rebuild of woodpeckerci/plugin-docker-buildx with the internal Vault-PKI CA baked in.

Why

The stock woodpeckerci/plugin-docker-buildx image does not trust artifactapi's internal CA, so k8s Woodpecker buildx jobs cannot push to artifactapi.k8s.syd1.au.unkin.net/docker-internal/* — buildkit needs /etc/docker/certs.d/<registry>/ca.crt inside the plugin container, and the k8s backend has no way to inject it.

This image copies the vault-ca-cert bundle (root + intermediate) into that path plus the system trust store, so pipelines can settings.registry: artifactapi.k8s.syd1.au.unkin.net and push over TLS.

Published as

artifactapi.k8s.syd1.au.unkin.net/docker-internal/plugin-docker-buildx:<tag> (and :latest)

Bootstrap

This image is itself built and pushed by buildah (.woodpecker/release.yaml), not by buildx, using buildah push --tls-verify=false. buildah is used precisely because it sidesteps the buildx CA-trust problem that this image exists to fix — its own push therefore cannot rely on that trust yet.

Once published, point Woodpecker docker-buildx steps at this image instead of the upstream one to push to the docker-internal registry.

S
Description
Woodpecker plugin-docker-buildx image with the internal Vault-PKI CA baked in (trusts artifactapi)
Readme 36 KiB
Languages
Dockerfile 100%