Remove build_args override so Kaniko pulls via Tailscale FQDN

ldraney commented

2026-06-04 04:37:14 +00:00

Owner

Summary

Remove build_args: "REGISTRY=harbor.harbor.svc.cluster.local" from .woodpecker.yaml
PR #76 added this override to avoid DERP relay failures, but it broke the opposite direction: Kaniko can't reliably pull base images from the cluster-internal address (HTTPS times out, HTTP refused)
The Dockerfile default (harbor.tail5b443a.ts.net) works for pulls; the registry setting still pushes via the cluster-internal address

Changes

.woodpecker.yaml: Remove build_args line from build-and-push step

Test Plan

Tests pass locally
Pipeline #171/#172/#173 failure pattern does not reproduce — build-and-push succeeds on merge to main
No regressions in lint, test, or image push

Review Checklist

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

ldraney/landscaping-assistant #77 — Kaniko build-arg override breaks base image pull
ldraney/landscaping-assistant #23 — parent CI optimization issue
landscaping-assistant — project this work belongs to

Closes #77

## Summary - Remove `build_args: "REGISTRY=harbor.harbor.svc.cluster.local"` from `.woodpecker.yaml` - PR #76 added this override to avoid DERP relay failures, but it broke the opposite direction: Kaniko can't reliably pull base images from the cluster-internal address (HTTPS times out, HTTP refused) - The Dockerfile default (`harbor.tail5b443a.ts.net`) works for pulls; the `registry` setting still pushes via the cluster-internal address ## Changes - `.woodpecker.yaml`: Remove `build_args` line from `build-and-push` step ## Test Plan - [ ] Tests pass locally - [ ] Pipeline #171/#172/#173 failure pattern does not reproduce — build-and-push succeeds on merge to main - [ ] No regressions in lint, test, or image push ## Review Checklist - [ ] Passed automated review-fix loop - [ ] No secrets committed - [ ] No unnecessary file changes - [ ] Commit messages are descriptive ## Related Notes - `ldraney/landscaping-assistant #77` — Kaniko build-arg override breaks base image pull - `ldraney/landscaping-assistant #23` — parent CI optimization issue - `landscaping-assistant` — project this work belongs to Closes #77

ldraney added 1 commit

2026-06-04 04:37:14 +00:00

Remove build_args override so Kaniko pulls via Tailscale FQDN

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

6882d9db6a

The build_args REGISTRY override forced Kaniko to pull base images
from harbor.harbor.svc.cluster.local, which times out intermittently.
The Dockerfile default (harbor.tail5b443a.ts.net) is reliable for
pulls; the registry setting still pushes via the cluster-internal
address.

Closes #77

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

ldraney commented

2026-06-04 04:38:07 +00:00

Author

Owner

PR #78 Review

DOMAIN REVIEW

Tech stack: Woodpecker CI / Kaniko / Docker (infrastructure/CI domain).

Analysis of the change: This is a single-line deletion removing build_args: "REGISTRY=harbor.harbor.svc.cluster.local" from the build-and-push step in .woodpecker.yaml.

The architecture is sound:

Dockerfile declares ARG REGISTRY=harbor.tail5b443a.ts.net (Tailscale FQDN) as the default on lines 4 and 19. Without the build_args override, Kaniko uses this default for FROM image pulls -- this is the reliable path.
registry: harbor.harbor.svc.cluster.local (line 47) controls where Kaniko pushes the built image. This remains set to the cluster-internal address, which is correct for push operations within the cluster.
PR #76 conflated the pull and push paths by overriding REGISTRY for both. This fix correctly restores the separation: pull via Tailscale FQDN, push via cluster-internal.

No concerns with the Kaniko plugin configuration. The insecure and insecure-registry settings correctly apply only to the push registry, not the pull source.

BLOCKERS

None.

This is a one-line config deletion with no new functionality, no user input handling, no auth logic, and no secrets exposure. No BLOCKER criteria are triggered.

NITS

None. The change is minimal and precisely scoped.

SOP COMPLIANCE

Branch named after issue: 77-fix-kaniko-registry-build-arg follows {issue-number}-{kebab-case-purpose} convention
PR body follows template: Summary, Changes, Test Plan, Review Checklist, Related Notes sections all present
Related Notes references parent issue #77 and upstream issue #23
Closes #77 present in PR body
No secrets committed -- credentials use from_secret references
No unnecessary file changes -- 1 file changed, 0 additions, 1 deletion
Commit messages are descriptive (verified from PR context)

PROCESS OBSERVATIONS

Change failure risk: Low. This reverts a known-broken change from PR #76. The Dockerfile default was working before #76 introduced the override.
Deployment frequency: This unblocks the CI pipeline, which is currently failing on main-branch builds. Merging restores deployment capability.
Test plan note: The test plan correctly identifies that validation requires a pipeline run on merge to main (pipelines #171-173 showed the failure pattern). This cannot be validated pre-merge in a PR-only context.

VERDICT: APPROVED

## PR #78 Review ### DOMAIN REVIEW **Tech stack**: Woodpecker CI / Kaniko / Docker (infrastructure/CI domain). **Analysis of the change**: This is a single-line deletion removing `build_args: "REGISTRY=harbor.harbor.svc.cluster.local"` from the `build-and-push` step in `.woodpecker.yaml`. The architecture is sound: - **Dockerfile** declares `ARG REGISTRY=harbor.tail5b443a.ts.net` (Tailscale FQDN) as the default on lines 4 and 19. Without the `build_args` override, Kaniko uses this default for `FROM` image pulls -- this is the reliable path. - **`registry: harbor.harbor.svc.cluster.local`** (line 47) controls where Kaniko pushes the built image. This remains set to the cluster-internal address, which is correct for push operations within the cluster. - PR #76 conflated the pull and push paths by overriding REGISTRY for both. This fix correctly restores the separation: pull via Tailscale FQDN, push via cluster-internal. No concerns with the Kaniko plugin configuration. The `insecure` and `insecure-registry` settings correctly apply only to the push registry, not the pull source. ### BLOCKERS None. This is a one-line config deletion with no new functionality, no user input handling, no auth logic, and no secrets exposure. No BLOCKER criteria are triggered. ### NITS None. The change is minimal and precisely scoped. ### SOP COMPLIANCE - [x] Branch named after issue: `77-fix-kaniko-registry-build-arg` follows `{issue-number}-{kebab-case-purpose}` convention - [x] PR body follows template: Summary, Changes, Test Plan, Review Checklist, Related Notes sections all present - [x] Related Notes references parent issue #77 and upstream issue #23 - [x] `Closes #77` present in PR body - [x] No secrets committed -- credentials use `from_secret` references - [x] No unnecessary file changes -- 1 file changed, 0 additions, 1 deletion - [x] Commit messages are descriptive (verified from PR context) ### PROCESS OBSERVATIONS - **Change failure risk**: Low. This reverts a known-broken change from PR #76. The Dockerfile default was working before #76 introduced the override. - **Deployment frequency**: This unblocks the CI pipeline, which is currently failing on main-branch builds. Merging restores deployment capability. - **Test plan note**: The test plan correctly identifies that validation requires a pipeline run on merge to main (pipelines #171-173 showed the failure pattern). This cannot be validated pre-merge in a PR-only context. ### VERDICT: APPROVED