Use build-arg for Dockerfile registry to avoid DERP relay failures

ldraney commented

2026-06-04 04:25:11 +00:00

Owner

Summary

Parameterizes Harbor registry in Dockerfile FROM statements with ARG REGISTRY defaulting to external URL
Kaniko build step overrides to internal URL via build_args, pulling base images directly instead of through the DERP relay
Local docker build still works without passing --build-arg (defaults to external)

Closes #73

Changes

Dockerfile: Add ARG REGISTRY=harbor.tail5b443a.ts.net, use ${REGISTRY} in both FROM statements
.woodpecker.yaml: Add build_args: "REGISTRY=harbor.harbor.svc.cluster.local" to Kaniko step

Test Plan

Pipeline build-and-push succeeds on this branch
Kaniko logs show image pull from harbor.harbor.svc.cluster.local, not harbor.tail5b443a.ts.net
Local docker build . still works without --build-arg
No DERP relay stream errors in build logs

Review Checklist

Passed automated review-fix loop
No secrets committed
No unnecessary file changes
Commit messages are descriptive

ldraney/landscaping-assistant #73 — Kaniko DERP relay fix
landscaping-assistant — project

## Summary - Parameterizes Harbor registry in Dockerfile FROM statements with `ARG REGISTRY` defaulting to external URL - Kaniko build step overrides to internal URL via `build_args`, pulling base images directly instead of through the DERP relay - Local `docker build` still works without passing `--build-arg` (defaults to external) Closes #73 ## Changes - `Dockerfile`: Add `ARG REGISTRY=harbor.tail5b443a.ts.net`, use `${REGISTRY}` in both FROM statements - `.woodpecker.yaml`: Add `build_args: "REGISTRY=harbor.harbor.svc.cluster.local"` to Kaniko step ## Test Plan - [ ] Pipeline build-and-push succeeds on this branch - [ ] Kaniko logs show image pull from `harbor.harbor.svc.cluster.local`, not `harbor.tail5b443a.ts.net` - [ ] Local `docker build .` still works without `--build-arg` - [ ] No DERP relay stream errors in build logs ## Review Checklist - [ ] Passed automated review-fix loop - [ ] No secrets committed - [ ] No unnecessary file changes - [ ] Commit messages are descriptive ## Related Notes - `ldraney/landscaping-assistant #73` — Kaniko DERP relay fix - `landscaping-assistant` — project

ldraney added 1 commit

2026-06-04 04:25:11 +00:00

Use build-arg for Dockerfile registry to avoid DERP relay failures

ci/woodpecker/push/woodpecker Pipeline was successful

Details

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

CI / scan_ruby (pull_request) Has been cancelled

Details

CI / scan_js (pull_request) Has been cancelled

Details

CI / lint (pull_request) Has been cancelled

Details

d0ade82f68

Parameterize the Harbor registry in FROM statements with ARG REGISTRY
defaulting to the external URL. Kaniko overrides to the internal URL
via build_args, avoiding Tailscale DERP relay for base image pulls.

Closes #73

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

ldraney commented

2026-06-04 04:26:31 +00:00

Author

Owner

PR #76 Review

DOMAIN REVIEW

Tech stack identified: Dockerfile (multi-stage build), Woodpecker CI (Kaniko plugin), YAML pipeline config.

Dockerfile changes (lines 4-5, 19-20):

ARG REGISTRY=harbor.tail5b443a.ts.net declared twice -- once before each FROM statement. This is correct and required by Docker's multi-stage build semantics: ARG declarations before FROM are scoped to the build-stage preamble and reset after each FROM. Each stage that needs the arg must redeclare it. Well done.
Default value harbor.tail5b443a.ts.net preserves local docker build . compatibility without requiring --build-arg. Correct.
The ${REGISTRY} interpolation in FROM lines is syntactically valid for BuildKit and Kaniko.

Woodpecker changes (line 50):

build_args: "REGISTRY=harbor.harbor.svc.cluster.local" passes the internal cluster-local Harbor URL to Kaniko, which overrides the default. This avoids routing image pulls through the Tailscale DERP relay. Correct approach.
The build_args value is consistent with the existing registry and insecure-registry settings on lines 47 and 49. Good internal consistency.

Observation -- hardcoded registry in other files:

docker-compose.yml (line 12) still hardcodes harbor.tail5b443a.ts.net/library/ruby-rails-build:latest for the dev web service image. This is acceptable since docker-compose runs locally and needs the external Tailscale URL. Not a bug, but worth noting for future parameterization if the registry URL ever changes.
.woodpecker.yaml lint and test steps (lines 17, 29) also hardcode harbor.tail5b443a.ts.net/library/ruby-rails-build:latest as their runner images. These are pulled by the Woodpecker agent (not Kaniko), so the build-arg pattern does not apply to them. If the DERP relay issue also affects agent image pulls, those would need a separate fix (image pull policy or agent-level mirror config). This is out of scope for this PR.

No secrets exposed: The registry URLs are infrastructure endpoints, not credentials. Harbor credentials are correctly sourced from from_secret references (lines 57-59).

BLOCKERS

None.

This is a CI/infrastructure-only change to Dockerfile build args and pipeline config. No application code, no user input handling, no new functionality requiring tests. The BLOCKER criteria (test coverage for new functionality, unvalidated input, secrets, DRY auth violations) do not apply.

NITS

Consistency nit (non-blocking): The ARG REGISTRY default includes the hostname but not the scheme. This is correct for Docker image references, but a brief inline comment like # Override via --build-arg REGISTRY=... for cluster-internal pulls would help future readers understand why the ARG exists. Very minor.
Repeated default value: The default harbor.tail5b443a.ts.net appears in two ARG declarations. If the external URL ever changes, both must be updated. A single-source-of-truth pattern is not possible here due to Docker's ARG scoping rules across FROM boundaries, so this is inherent to the design. No action needed, just documenting for awareness.

SOP COMPLIANCE

Branch named after issue: 73-kaniko-build-arg-registry follows {issue-number}-{kebab-case-purpose}
PR body follows template: Summary, Changes, Test Plan, Review Checklist, Related Notes all present
Related references plan slug: No plan slug referenced. Caller indicated no plan slug exists, so this is noted but not blocking.
No secrets committed: Registry URLs are not secrets; actual credentials use from_secret
No unnecessary file changes: Only Dockerfile and .woodpecker.yaml modified, both directly relevant
Commit messages: PR title is descriptive and matches the change

PROCESS OBSERVATIONS

Change failure risk: Low. The change is mechanically simple (parameterize a hardcoded value with a default that preserves existing behavior). The only risk is if Kaniko's build_args syntax differs from expectations, which the Test Plan correctly covers.
Deployment frequency impact: Positive. This unblocks the build pipeline that was failing due to DERP relay stream errors, restoring the ability to ship.
Test Plan quality: The four checklist items (pipeline success, Kaniko logs showing internal URL, local docker build still works, no DERP errors) are appropriate and sufficient for this infrastructure change. Automated test coverage is not applicable here -- this is CI config, not application code.

VERDICT: APPROVED

## PR #76 Review ### DOMAIN REVIEW **Tech stack identified:** Dockerfile (multi-stage build), Woodpecker CI (Kaniko plugin), YAML pipeline config. **Dockerfile changes (lines 4-5, 19-20):** - `ARG REGISTRY=harbor.tail5b443a.ts.net` declared twice -- once before each `FROM` statement. This is correct and required by Docker's multi-stage build semantics: `ARG` declarations before `FROM` are scoped to the build-stage preamble and reset after each `FROM`. Each stage that needs the arg must redeclare it. Well done. - Default value `harbor.tail5b443a.ts.net` preserves local `docker build .` compatibility without requiring `--build-arg`. Correct. - The `${REGISTRY}` interpolation in `FROM` lines is syntactically valid for BuildKit and Kaniko. **Woodpecker changes (line 50):** - `build_args: "REGISTRY=harbor.harbor.svc.cluster.local"` passes the internal cluster-local Harbor URL to Kaniko, which overrides the default. This avoids routing image pulls through the Tailscale DERP relay. Correct approach. - The `build_args` value is consistent with the existing `registry` and `insecure-registry` settings on lines 47 and 49. Good internal consistency. **Observation -- hardcoded registry in other files:** - `docker-compose.yml` (line 12) still hardcodes `harbor.tail5b443a.ts.net/library/ruby-rails-build:latest` for the dev `web` service image. This is acceptable since docker-compose runs locally and needs the external Tailscale URL. Not a bug, but worth noting for future parameterization if the registry URL ever changes. - `.woodpecker.yaml` lint and test steps (lines 17, 29) also hardcode `harbor.tail5b443a.ts.net/library/ruby-rails-build:latest` as their runner images. These are pulled by the Woodpecker agent (not Kaniko), so the build-arg pattern does not apply to them. If the DERP relay issue also affects agent image pulls, those would need a separate fix (image pull policy or agent-level mirror config). This is out of scope for this PR. **No secrets exposed:** The registry URLs are infrastructure endpoints, not credentials. Harbor credentials are correctly sourced from `from_secret` references (lines 57-59). ### BLOCKERS None. This is a CI/infrastructure-only change to Dockerfile build args and pipeline config. No application code, no user input handling, no new functionality requiring tests. The BLOCKER criteria (test coverage for new functionality, unvalidated input, secrets, DRY auth violations) do not apply. ### NITS 1. **Consistency nit (non-blocking):** The `ARG REGISTRY` default includes the hostname but not the scheme. This is correct for Docker image references, but a brief inline comment like `# Override via --build-arg REGISTRY=... for cluster-internal pulls` would help future readers understand why the ARG exists. Very minor. 2. **Repeated default value:** The default `harbor.tail5b443a.ts.net` appears in two `ARG` declarations. If the external URL ever changes, both must be updated. A single-source-of-truth pattern is not possible here due to Docker's `ARG` scoping rules across `FROM` boundaries, so this is inherent to the design. No action needed, just documenting for awareness. ### SOP COMPLIANCE - [x] Branch named after issue: `73-kaniko-build-arg-registry` follows `{issue-number}-{kebab-case-purpose}` - [x] PR body follows template: Summary, Changes, Test Plan, Review Checklist, Related Notes all present - [ ] Related references plan slug: No plan slug referenced. Caller indicated no plan slug exists, so this is noted but not blocking. - [x] No secrets committed: Registry URLs are not secrets; actual credentials use `from_secret` - [x] No unnecessary file changes: Only `Dockerfile` and `.woodpecker.yaml` modified, both directly relevant - [x] Commit messages: PR title is descriptive and matches the change ### PROCESS OBSERVATIONS - **Change failure risk:** Low. The change is mechanically simple (parameterize a hardcoded value with a default that preserves existing behavior). The only risk is if Kaniko's `build_args` syntax differs from expectations, which the Test Plan correctly covers. - **Deployment frequency impact:** Positive. This unblocks the build pipeline that was failing due to DERP relay stream errors, restoring the ability to ship. - **Test Plan quality:** The four checklist items (pipeline success, Kaniko logs showing internal URL, local docker build still works, no DERP errors) are appropriate and sufficient for this infrastructure change. Automated test coverage is not applicable here -- this is CI config, not application code. ### VERDICT: APPROVED