ci: use the remote buildx driver, and build amd64 only

Conversation 3 Commits 2 Files Changed 1

+27 -12

2 Commits

Author	SHA1	Message	Date
hermes	a48fb1c566	ci: drop the kubeconfig from the build job Build and Push Image / Unit tests (push) Successful in 41s Details Build and Push Image / Build and push image (push) Skipped Details The independent review flagged that the build job wrote the `KUBEC_CONFIG_BUILDX` secret to disk even though the build does not need cluster access at all. That secret is cluster-admin-equivalent: a build step that never talks to the cluster should not be able to read it, and a compromised dependency in the build would otherwise have a direct path to the cluster. The "Create Kubeconfig" step is removed from the build job. The deploy step, added in a later PR, gets its own job with the kubeconfig - so the privilege is only present where it is actually used. Also checked the buildkit daemon's resources in response to the review: it already has limits (2 CPU, 4Gi memory, 2Gi ephemeral storage) and requests (500m, 1Gi). The crash that motivated the amd64-only change was qemu exhausting memory during multi-arch emulation, not an unconstrained daemon, so no change is needed there.	2026-11-09 11:01:59 +10:00
hermes	e9ce0dcf9b	ci: use the remote buildx driver, and build amd64 only Build and Push Image / Unit tests (push) Successful in 46s Details Build and Push Image / Build and push image (push) Skipped Details The build job failed at "Set up Docker Buildx": Error: ERROR: error for bootstrap "builder-...": Get "https://192.168.178.160:6443/apis/apps/v1/namespaces/gitea-runner/deployments/builder-...": tls: failed to verify certificate: x509: certificate signed by unknown authority Cause ------ The `kubernetes` buildx driver talks to the cluster API to create its builder pods. That needs the k3s CA certificate, which the job container does not have - the `catthehacker/ubuntu:act-latest` image ships the public CA set only. So the bootstrap could not verify the API server. Fix --- Switch to the `remote` driver, which talks straight to the buildkit daemon already running in the cluster: driver: remote endpoint: tcp://buildkit.gitea-runner.svc:1234 No cluster API access is needed at all, so no kubeconfig is needed for the build. This is the same pattern the wedding-photos workflow uses. `endpoint` must be a top-level key, not a driver-opt: the action appends it as the POSITIONAL argument to `buildx create --driver remote <endpoint>`, and passing it in driver-opts yields "ERROR: no remote endpoint provided". Also ---- The build was multi-arch (linux/amd64,linux/arm64), which runs qemu emulation and crashes the buildkit pod on this NUC (exit 255, SandboxChanged), after which the build hangs for many minutes. The cluster is amd64, so the image is built for linux/amd64 only. Verified: `docker buildx create --driver remote tcp://buildkit.gitea-runner.svc:1234` succeeds from the runner's dind container and reports buildkit v0.29.0 with linux/amd64 among its supported platforms.	2026-11-09 10:58:28 +10:00

Author

SHA1

Message

Date

hermes

a48fb1c566

ci: drop the kubeconfig from the build job

Build and Push Image / Unit tests (push) Successful in 41s

Details

Build and Push Image / Build and push image (push) Skipped

Details

The independent review flagged that the build job wrote the
`KUBEC_CONFIG_BUILDX` secret to disk even though the build does not need
cluster access at all. That secret is cluster-admin-equivalent: a build step
that never talks to the cluster should not be able to read it, and a
compromised dependency in the build would otherwise have a direct path to the
cluster.

The "Create Kubeconfig" step is removed from the build job. The deploy step,
added in a later PR, gets its own job with the kubeconfig - so the privilege
is only present where it is actually used.

Also checked the buildkit daemon's resources in response to the review: it
already has limits (2 CPU, 4Gi memory, 2Gi ephemeral storage) and requests
(500m, 1Gi). The crash that motivated the amd64-only change was qemu
exhausting memory during multi-arch emulation, not an unconstrained daemon, so
no change is needed there.

2026-11-09 11:01:59 +10:00

hermes

e9ce0dcf9b

ci: use the remote buildx driver, and build amd64 only

Build and Push Image / Unit tests (push) Successful in 46s

Details

Build and Push Image / Build and push image (push) Skipped

Details

The build job failed at "Set up Docker Buildx":

    Error: ERROR: error for bootstrap "builder-...":
    Get "https://192.168.178.160:6443/apis/apps/v1/namespaces/gitea-runner/deployments/builder-...":
    tls: failed to verify certificate: x509: certificate signed by unknown authority

Cause
------
The `kubernetes` buildx driver talks to the cluster API to create its builder
pods. That needs the k3s CA certificate, which the job container does not
have - the `catthehacker/ubuntu:act-latest` image ships the public CA set
only. So the bootstrap could not verify the API server.

Fix
---
Switch to the `remote` driver, which talks straight to the buildkit daemon
already running in the cluster:

    driver: remote
    endpoint: tcp://buildkit.gitea-runner.svc:1234

No cluster API access is needed at all, so no kubeconfig is needed for the
build. This is the same pattern the wedding-photos workflow uses.

`endpoint` must be a top-level key, not a driver-opt: the action appends it
as the POSITIONAL argument to `buildx create --driver remote <endpoint>`, and
passing it in driver-opts yields "ERROR: no remote endpoint provided".

Also
----
The build was multi-arch (linux/amd64,linux/arm64), which runs qemu
emulation and crashes the buildkit pod on this NUC (exit 255,
SandboxChanged), after which the build hangs for many minutes. The cluster
is amd64, so the image is built for linux/amd64 only.

Verified: `docker buildx create --driver remote tcp://buildkit.gitea-runner.svc:1234`
succeeds from the runner's dind container and reports buildkit v0.29.0 with
linux/amd64 among its supported platforms.

2026-11-09 10:58:28 +10:00

ci: use the remote buildx driver, and build amd64 only #6