setup-buildx/README.md

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.

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 build reuses the cluster's BuildKit instance (persistent 100 GiB Longhorn PVC + tuned GC) for layer caching across runs.

Usage

jobs:
  build:
    runs-on: aceofba-cluster
    container:
      image: ghcr.io/catthehacker/ubuntu:act-22.04
    steps:
      - uses: actions/checkout@v4

      - uses: https://git.aceofba.se/infra/setup-buildx@v1

      - uses: docker/build-push-action@v6
        with:
          context: .
          file: Dockerfile
          push: true
          tags: git.aceofba.se/${{ github.repository }}:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

Inputs

Name	Default	Description
endpoint	tcp://buildkit.gitea.svc.cluster.local:1234	BuildKit TCP endpoint. Override only if you run a private buildkit somewhere else.
version	latest	buildx version, passed through to the upstream action.

Why

docker/setup-buildx-action@v3 defaults to driver: docker-container, which requires a working Docker daemon inside the job container. The act-runner uses Kubernetes pod-per-job hooks — there is no dockerd in those pods. The cluster does run a standalone BuildKit Service (buildkit-service Helm chart, port 1234) which buildx can talk to via its remote driver. This action wires that in by default.

cache-from/cache-to: type=gha also works out of the box: the act-runner image (christopherhx/gitea-actions-runner) ships its own embedded Actions 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.