infra/setup-buildx
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: default to the buildkit in the caller's own namespace

Browse Source 
The default was `tcp://buildkit.gitea.svc.cluster.local:1234`, which
names aceofbase's namespace explicitly. That was correct while aceofbase
was the only cluster running CI, and resolves to nothing from
planet-express — so every workflow moved to the new dink-backed runner
had to override it, and forgetting produced a DNS error from inside
buildx that named neither this action nor the cluster it pointed at.

A BARE Service name resolves in the job container's own namespace, which
is where its runner's buildkit lives on both clusters: `gitea` on
aceofbase, `gitea-runner` on planet-express. One default, correct on
both, and correct for a cluster nobody has built yet.

Verified before changing rather than assumed: on aceofbase the buildkit
Service is in `gitea`, and gitea-act-runner's Role is namespace-scoped
to `gitea`, so its job pods land in the same namespace as the Service.
Existing consumers therefore see no change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C1tzpqzv37DDbtpPTxHsyA
This commit is contained in:
Anders Olsson
2026-08-18 06:25:35 +02:00
co-authored by Claude Opus 5
parent 917bedaf7c
commit 17d77ace6a
2 changed files with 32 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+16 -3
View File
@@ -1,8 +1,7 @@
# setup-buildx
Drop-in replacement for `docker/setup-buildx-action@v3` that defaults to the
in-cluster `buildkit.gitea.svc.cluster.local:1234` service in the aceofbase
cluster.
`buildkit` service in the calling job's own namespace.
Use this whenever a Gitea Actions workflow needs to build images. It removes
the boilerplate of declaring a remote driver every time, and ensures every
@@ -36,7 +35,7 @@ jobs:
| Name | Default | Description |
|------|---------|-------------|
| `endpoint` | `tcp://buildkit.gitea.svc.cluster.local:1234` | BuildKit TCP endpoint. Override only if you run a private buildkit somewhere else. |
| `endpoint` | `tcp://buildkit:1234` | BuildKit TCP endpoint. A bare Service name, so it resolves in the job's own namespace. Override only if you run a private buildkit somewhere else. |
| `version` | `latest` | buildx version, passed through to the upstream action. |
## Why
@@ -54,3 +53,17 @@ Cache / Results API and injects `ACTIONS_CACHE_URL` / `ACTIONS_RUNTIME_TOKEN`
into the job container. That cache is persisted on the runner's `/data` PVC,
so it survives pod restarts. There is no separate cache-server deployment to
configure.
## Why the endpoint is a bare Service name
A job container resolves a bare Service name in its own namespace, which is
where its runner's buildkit lives on every cluster here — `gitea` on
aceofbase, `gitea-runner` on planet-express. One default is therefore correct
on both, and stays correct for a cluster nobody has built yet.
Until 2026-08-18 it defaulted to `tcp://buildkit.gitea.svc.cluster.local:1234`,
naming aceofbase's namespace explicitly. That was fine while aceofbase was the
only cluster running CI. It resolved to nothing from planet-express, so every
workflow moved there had to pass `endpoint:` by hand, and forgetting produced a
DNS error from inside buildx that named neither this action nor the cluster it
was pointing at.