#26 - Push images to the in-cluster Forgejo registry instead of the public ingress #27

Merged

GuillaumeHemmen merged 2 commits from 26-push-to-in-cluster-registry into master

2026-09-11 06:22:32 +00:00

claude-bot commented

2026-09-10 11:40:21 +00:00

Member

What

The dev and tag workflows now push images to Forgejo's in-cluster Service (app-http-service.forgejo.svc.cluster.local:3000) over plain HTTP, instead of to git.van-hemmen.com.

Why

See #26. The coder-xfce-vnc job builds fine, then fails pushing: PATCH …/blobs/uploads/…: 502 Bad Gateway. On Forgejo's side, those uploads ended with unexpected EOF after 60.0–60.7 s.

The runner pods and Forgejo both run on talos-ovh-worker-two, but git.van-hemmen.com resolves to the ingress on talos-ovh-gateway-one. Every layer went out through Traefik and back, and Traefik cuts any single request that runs longer than about a minute. The runner itself already talks to Forgejo through http://app-http-service:3000; with this change, the image push does too. Node-to-node traffic goes through WireGuard.

Changes

.forgejo/workflows/docker-dev.yaml and docker-tag.yaml (all 6 jobs):
- REGISTRY_HOST: app-http-service.forgejo.svc.cluster.local:3000 and REGISTRY_INSECURE: 'true', the settings added in actions/kaniko#8.
- Every KANIKO_DESTINATION uses that host. The image names and tags are unchanged (ci-${GITHUB_SHA}, coder-xfce-vnc-latest, latest, …).
- container.image is git.van-hemmen.com/actions/kaniko:26.37.0, the release that ships REGISTRY_INSECURE. The first commit used the actions/kaniko#8 branch build (ce7d0b7a) for the end-to-end test; a74d690 switches to the release.
README.md: a paragraph in "CI/CD Workflows" on where images are pushed, and why.

Forgejo stores container images by owner and name, not by hostname, so pulls stay git.van-hemmen.com/actions/sindri:<tag>. Its login request still goes to the public https://git.van-hemmen.com/v2/token: one small HTTPS request per push, while the layer data goes to the Service.

Verification

/v2/ on the internal Service answers 401 with Docker-Distribution-Api-Version: registry/2.0 and the same Www-Authenticate realm as the public URL (checked from a pod).
docker-tag.yaml has no remaining git.van-hemmen.com/actions/sindri: destinations, and both files parse as YAML.
End-to-end test (run 77, commit 9092d17, kaniko branch build): all three jobs green, including coder-xfce-vnc (9m37s), which failed at the push on #22 and #23.
- ci-, coder- and coder-xfce-vnc-9092d17… all appear under the actions/sindri container package.
- Fetching the coder-xfce-vnc-9092d17… manifest through https://git.van-hemmen.com/v2/… returns 200, so pulls under the public name work.
- Forgejo's log shows the 37 blob uploads coming straight from runner pod IPs (10.244.34.197/.229/.214), not the ingress path. All returned 202; the largest took 31.7 s.
Commit a74d690 (kaniko 26.37.0) runs the same pipeline with the released image.
Not exercised: docker-tag.yaml only runs on a tag push, but it's the same change applied to its destinations.

Merge order

~~actions/kaniko#8 merged and released as 26.37.0.~~ Done.
This PR merged once a74d690's CI is green.
#22 and #23 rebased.

Closes #26

🤖 Generated with Claude Code

https://claude.ai/code/session_01XPajGyTH2js52mY5WSJoNA

## What The dev and tag workflows now push images to **Forgejo's in-cluster Service** (`app-http-service.forgejo.svc.cluster.local:3000`) over plain HTTP, instead of to `git.van-hemmen.com`. ## Why See #26. The `coder-xfce-vnc` job builds fine, then fails pushing: `PATCH …/blobs/uploads/…: 502 Bad Gateway`. On Forgejo's side, those uploads ended with `unexpected EOF` after 60.0–60.7 s. The runner pods and Forgejo both run on `talos-ovh-worker-two`, but `git.van-hemmen.com` resolves to the ingress on `talos-ovh-gateway-one`. Every layer went out through Traefik and back, and Traefik cuts any single request that runs longer than about a minute. The runner itself already talks to Forgejo through `http://app-http-service:3000`; with this change, the image push does too. Node-to-node traffic goes through WireGuard. ## Changes - **`.forgejo/workflows/docker-dev.yaml`** and **`docker-tag.yaml`** (all 6 jobs): - `REGISTRY_HOST: app-http-service.forgejo.svc.cluster.local:3000` and `REGISTRY_INSECURE: 'true'`, the settings added in actions/kaniko#8. - Every `KANIKO_DESTINATION` uses that host. The image names and tags are unchanged (`ci-${GITHUB_SHA}`, `coder-xfce-vnc-latest`, `latest`, …). - `container.image` is `git.van-hemmen.com/actions/kaniko:26.37.0`, the release that ships `REGISTRY_INSECURE`. The first commit used the actions/kaniko#8 branch build (`ce7d0b7a`) for the end-to-end test; `a74d690` switches to the release. - **`README.md`**: a paragraph in "CI/CD Workflows" on where images are pushed, and why. Forgejo stores container images by owner and name, not by hostname, so pulls stay `git.van-hemmen.com/actions/sindri:<tag>`. Its login request still goes to the public `https://git.van-hemmen.com/v2/token`: one small HTTPS request per push, while the layer data goes to the Service. ## Verification - `/v2/` on the internal Service answers `401` with `Docker-Distribution-Api-Version: registry/2.0` and the same `Www-Authenticate` realm as the public URL (checked from a pod). - `docker-tag.yaml` has no remaining `git.van-hemmen.com/actions/sindri:` destinations, and both files parse as YAML. - **End-to-end test (run 77, commit `9092d17`, kaniko branch build):** all three jobs green, including `coder-xfce-vnc` (9m37s), which failed at the push on #22 and #23. - `ci-`, `coder-` and `coder-xfce-vnc-9092d17…` all appear under the `actions/sindri` container package. - Fetching the `coder-xfce-vnc-9092d17…` manifest through `https://git.van-hemmen.com/v2/…` returns `200`, so pulls under the public name work. - Forgejo's log shows the 37 blob uploads coming straight from runner pod IPs (`10.244.34.197/.229/.214`), not the ingress path. All returned `202`; the largest took 31.7 s. - Commit `a74d690` (kaniko `26.37.0`) runs the same pipeline with the released image. - Not exercised: `docker-tag.yaml` only runs on a tag push, but it's the same change applied to its destinations. ## Merge order 1. ~~actions/kaniko#8 merged and released as `26.37.0`.~~ Done. 2. This PR merged once `a74d690`'s CI is green. 3. #22 and #23 rebased. Closes #26 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01XPajGyTH2js52mY5WSJoNA

claude-bot added 1 commit

2026-09-10 11:40:21 +00:00

#26 - Push images to the in-cluster Forgejo registry instead of the public ingress

/ docker-dev-ci (push) Successful in 3m32s

Details

/ docker-dev-coder (push) Successful in 4m10s

Details

/ docker-dev-coder-xfce-vnc (push) Successful in 9m37s

Details

9092d17ec1

The coder-xfce-vnc job builds, then fails pushing: the public ingress
cuts blob uploads after ~60s (502 on PATCH, Forgejo logs unexpected EOF).
The runners and Forgejo share a node, so push to Forgejo's Service
(app-http-service.forgejo.svc.cluster.local:3000) over plain HTTP via
the kaniko wrapper's REGISTRY_HOST and REGISTRY_INSECURE, in both the dev
and tag workflows. Pulls stay git.van-hemmen.com/actions/sindri:<tag>.

The kaniko image is temporarily pinned to the actions/kaniko#8 branch
build (ce7d0b7a) to test end to end; switch it to the release tag once
that PR is merged and tagged.

Closes #26

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPajGyTH2js52mY5WSJoNA

claude-bot added 1 commit

2026-09-10 11:56:22 +00:00

#26 - Pin the kaniko builder to the 26.37.0 release

/ docker-dev-ci (push) Successful in 3m26s

Details

/ docker-dev-coder (push) Successful in 4m28s

Details

/ docker-dev-coder-xfce-vnc (push) Successful in 9m23s

Details

a74d690261

Replace the temporary actions/kaniko#8 branch build (ce7d0b7a) with the
released image that ships REGISTRY_INSECURE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XPajGyTH2js52mY5WSJoNA