#7 - Add REGISTRY_INSECURE to push to an in-cluster registry over plain HTTP #8

Merged

GuillaumeHemmen merged 1 commit from 7-add-insecure-registry-option into master

2026-09-10 11:51:18 +00:00

claude-bot commented

2026-09-10 11:38:52 +00:00

Member

What

Adds a REGISTRY_INSECURE setting to build.sh (default false). When set to true, the wrapper passes Kaniko's --insecure-registry=${REGISTRY_HOST}, so a pipeline can push to Forgejo's in-cluster Service over plain HTTP instead of through the public ingress.

Why

See #7. The runners and Forgejo run on the same node, but pushes to git.van-hemmen.com go out through Traefik and back. Traefik's ~60 s per-request timeout cuts large layer uploads, and actions/sindri's coder-xfce-vnc builds fail at the push with PATCH …/blobs/uploads/…: 502 Bad Gateway. Forgejo logs unexpected EOF on uploads lasting 60.0–60.7 s.

Changes

build.sh
- New REGISTRY_INSECURE setting: true/TRUE/True/1/yes enables it; false/0/no/empty leaves it off. It's checked right after the defaults are set, so an invalid value stops the job before any build work.
- When enabled, --insecure-registry=${REGISTRY_HOST} is added to the Kaniko call. That flag covers only the named registry, so pulls from Docker Hub and other registries keep using TLS.
- REGISTRY_INSECURE is shown in the settings summary printed before the build.
- With the setting unset or false, the Kaniko command is byte-for-byte the same as today.
README.md: new row in the settings table, plus a "Pushing to an in-cluster registry" section with example settings. It notes that REGISTRY_HOST must match the destination host (port included), that pulls stay git.van-hemmen.com/…, and that Forgejo's login request still goes to its public URL.

Verification

The Kaniko executor inside actions/kaniko:26.7.0 supports --insecure-registry ("Insecure registry using plain HTTP to push and pull"), checked with /kaniko/executor --help in a pod.
I ran the modified build.sh in that image's /busybox/sh, with the exec /kaniko/executor line replaced by echo:

Case	Result
Unset	`… --dockerfile=./Dockerfile --no-push` (unchanged)
`REGISTRY_INSECURE=false`	unchanged
`true` + `REGISTRY_HOST=app-http-service.forgejo.svc.cluster.local:3000` + destination	`… --target=ci --insecure-registry=app-http-service.forgejo.svc.cluster.local:3000 --destination=app-http-service.forgejo.svc.cluster.local:3000/actions/sindri:ci-abc`; `config.json` keyed on that host:port
`REGISTRY_INSECURE=ture`	`Error: REGISTRY_INSECURE must be true or false (got 'ture').`, exit 1

sh -n passes. shellcheck -s sh reports nothing new: a warning on the existing eval on line 10, and SC2086 infos on the intentionally unquoted $…_FLAG arguments, which follow the existing $TARGET_FLAG/$DEST_FLAGS pattern.

Not yet verified: an actual push through the internal Service. Pushing this branch makes docker-dev publish git.van-hemmen.com/actions/kaniko:<sha>. A companion actions/sindri branch uses that image with REGISTRY_INSECURE=true as the end-to-end test, and I'll report the result on this PR.

After merge

Tag a release so actions/sindri's workflows can pin the new version.

Closes #7

🤖 Generated with Claude Code

https://claude.ai/code/session_01XPajGyTH2js52mY5WSJoNA

## What Adds a **`REGISTRY_INSECURE`** setting to `build.sh` (default `false`). When set to `true`, the wrapper passes Kaniko's `--insecure-registry=${REGISTRY_HOST}`, so a pipeline can push to Forgejo's in-cluster Service over plain HTTP instead of through the public ingress. ## Why See #7. The runners and Forgejo run on the same node, but pushes to `git.van-hemmen.com` go out through Traefik and back. Traefik's ~60 s per-request timeout cuts large layer uploads, and `actions/sindri`'s `coder-xfce-vnc` builds fail at the push with `PATCH …/blobs/uploads/…: 502 Bad Gateway`. Forgejo logs `unexpected EOF` on uploads lasting 60.0–60.7 s. ## Changes - **`build.sh`** - New `REGISTRY_INSECURE` setting: `true`/`TRUE`/`True`/`1`/`yes` enables it; `false`/`0`/`no`/empty leaves it off. It's checked right after the defaults are set, so an invalid value stops the job before any build work. - When enabled, `--insecure-registry=${REGISTRY_HOST}` is added to the Kaniko call. That flag covers only the named registry, so pulls from Docker Hub and other registries keep using TLS. - `REGISTRY_INSECURE` is shown in the settings summary printed before the build. - With the setting unset or `false`, the Kaniko command is byte-for-byte the same as today. - **`README.md`**: new row in the settings table, plus a "Pushing to an in-cluster registry" section with example settings. It notes that `REGISTRY_HOST` must match the destination host (port included), that pulls stay `git.van-hemmen.com/…`, and that Forgejo's login request still goes to its public URL. ## Verification - The Kaniko executor inside `actions/kaniko:26.7.0` supports `--insecure-registry` ("Insecure registry using plain HTTP to push and pull"), checked with `/kaniko/executor --help` in a pod. - I ran the modified `build.sh` in that image's `/busybox/sh`, with the `exec /kaniko/executor` line replaced by `echo`: | Case | Result | |---|---| | Unset | `… --dockerfile=./Dockerfile --no-push` (unchanged) | | `REGISTRY_INSECURE=false` | unchanged | | `true` + `REGISTRY_HOST=app-http-service.forgejo.svc.cluster.local:3000` + destination | `… --target=ci --insecure-registry=app-http-service.forgejo.svc.cluster.local:3000 --destination=app-http-service.forgejo.svc.cluster.local:3000/actions/sindri:ci-abc`; `config.json` keyed on that host:port | | `REGISTRY_INSECURE=ture` | `Error: REGISTRY_INSECURE must be true or false (got 'ture').`, exit 1 | - `sh -n` passes. `shellcheck -s sh` reports nothing new: a warning on the existing `eval` on line 10, and SC2086 infos on the intentionally unquoted `$…_FLAG` arguments, which follow the existing `$TARGET_FLAG`/`$DEST_FLAGS` pattern. **Not yet verified:** an actual push through the internal Service. Pushing this branch makes `docker-dev` publish `git.van-hemmen.com/actions/kaniko:<sha>`. A companion `actions/sindri` branch uses that image with `REGISTRY_INSECURE=true` as the end-to-end test, and I'll report the result on this PR. ## After merge Tag a release so `actions/sindri`'s workflows can pin the new version. Closes #7 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01XPajGyTH2js52mY5WSJoNA

claude-bot added 1 commit

2026-09-10 11:38:52 +00:00

#7 - Add REGISTRY_INSECURE to push to an in-cluster registry over plain HTTP

/ docker-dev (push) Successful in 19s

Details

/ docker-pr (pull_request) Successful in 16s

Details

ce7d0b7a98

Pushing to the public registry hostname sends every layer out through the
ingress and back, where its ~60s request timeout cuts large layer uploads
(502 on blob PATCH). REGISTRY_INSECURE=true passes Kaniko's
--insecure-registry for REGISTRY_HOST only, so a pipeline can push to
Forgejo's Service (app-http-service.forgejo.svc.cluster.local:3000)
directly. Other registries keep TLS, and an invalid value fails before
the build starts. README documents the setting and the in-cluster setup.

Closes #7

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

claude-bot referenced this pull request from actions/sindri

2026-09-10 11:39:18 +00:00

Image pushes fail with 502 through the public ingress; push to the in-cluster registry instead #26

claude-bot referenced this pull request from a commit

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

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

claude-bot referenced this pull request from actions/sindri

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

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