Enable Kaniko registry-based layer caching

ldraney commented

2026-06-05 03:52:29 +00:00

Owner

Summary

Enable Kaniko registry-based layer caching to cut ~2-3 min off Docker builds when Gemfile.lock is unchanged (most merges).

Changes

Add cache: true and cache_repo settings to the Kaniko build-and-push step in .woodpecker.yaml
Kaniko pushes intermediate layer snapshots to harbor.harbor.svc.cluster.local/landscaping-assistant/cache
On subsequent builds, unchanged layers (base image pull, bundle install, bootsnap precompile) are served from cache instead of rebuilt
Harbor auto-creates the cache repo on first push within the existing landscaping-assistant project

Test Plan

PR pipeline passes lint + test (cache settings only affect build-and-push, which is main-only)
After merge to main, verify build-and-push completes successfully with cache enabled
Verify landscaping-assistant/cache repo appears in Harbor with cached layers
On second merge to main (without Gemfile changes), confirm Kaniko logs show cache hits and reduced build time

Review Checklist

Change is scoped — only modifies .woodpecker.yaml
No secrets or credentials exposed
No unrelated changes

docs/infrastructure-and-pipeline.md — pipeline docs (will update after confirming cache works)
Follows the Kaniko registry architecture established in PR #91

Closes #106

## Summary Enable Kaniko registry-based layer caching to cut ~2-3 min off Docker builds when Gemfile.lock is unchanged (most merges). ## Changes - Add `cache: true` and `cache_repo` settings to the Kaniko build-and-push step in `.woodpecker.yaml` - Kaniko pushes intermediate layer snapshots to `harbor.harbor.svc.cluster.local/landscaping-assistant/cache` - On subsequent builds, unchanged layers (base image pull, bundle install, bootsnap precompile) are served from cache instead of rebuilt - Harbor auto-creates the `cache` repo on first push within the existing `landscaping-assistant` project ## Test Plan - [ ] PR pipeline passes lint + test (cache settings only affect build-and-push, which is main-only) - [ ] After merge to main, verify build-and-push completes successfully with cache enabled - [ ] Verify `landscaping-assistant/cache` repo appears in Harbor with cached layers - [ ] On second merge to main (without Gemfile changes), confirm Kaniko logs show cache hits and reduced build time ## Review Checklist - [x] Change is scoped — only modifies `.woodpecker.yaml` - [x] No secrets or credentials exposed - [x] No unrelated changes ## Related Notes - `docs/infrastructure-and-pipeline.md` — pipeline docs (will update after confirming cache works) - Follows the Kaniko registry architecture established in PR #91 Closes #106

ldraney added 1 commit

2026-06-05 03:52:30 +00:00

Enable Kaniko registry-based layer caching for Docker builds

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

602678e755

Kaniko rebuilds all layers from scratch on every merge to main (~5-6 min).
Most merges don't change Gemfile.lock, so the expensive bundle install +
bootsnap precompile layers are identical. Registry-based caching pushes
intermediate layer snapshots to harbor/landscaping-assistant/cache and
skips unchanged layers on subsequent builds.

Expected savings: ~2-3 min per build when Gemfile is unchanged.

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

ldraney commented

2026-06-05 03:54:05 +00:00

Author

Owner

PR #106 Review

DOMAIN REVIEW

Tech stack: Woodpecker CI pipeline config (.woodpecker.yaml) with Kaniko Docker builder pushing to Harbor registry. The change is a 2-line addition to enable registry-based layer caching.

Kaniko cache configuration: The two new settings are correct for the woodpeckerci/plugin-kaniko plugin:

cache: true enables Kaniko's --cache=true flag
cache_repo points to a dedicated cache repository within the same Harbor instance

Registry consistency: The cache_repo uses harbor.harbor.svc.cluster.local which matches the registry and insecure-registry values already set on lines 62-64. This is the in-cluster service FQDN -- correct for a Woodpecker runner executing inside the same k8s cluster.

Insecure registry: The cache repo is on the same harbor.harbor.svc.cluster.local host that is already listed under insecure and insecure-registry. Kaniko should inherit these settings for cache pulls/pushes. No additional insecure flags needed.

Layer caching effectiveness: The Dockerfile is well-structured for caching -- Gemfile and Gemfile.lock are copied before bundle install, so the expensive dependency layer will be cached when only application code changes. The PR description's claim of ~2-3 min savings on unchanged Gemfile merges is plausible.

Multi-stage build note: The Dockerfile uses a multi-stage build (AS build then a runtime stage). Kaniko handles multi-stage caching correctly with --cache=true, caching intermediate layers from all stages.

No domain concerns.

BLOCKERS

None.

This is a CI configuration change -- no application code, no user input, no auth logic, no secrets exposed. The cache_repo value is an internal cluster address, not a secret. Credentials remain sourced from from_secret references. No BLOCKER criteria are triggered.

NITS

Cache TTL not specified: Kaniko supports --cache-ttl to control how long cached layers are retained. Without it, cached layers persist indefinitely in the Harbor cache repo. This is fine for now but worth considering if Harbor storage becomes a concern. Non-blocking.
No cache_copy_layers setting: The plugin supports cache_copy_layers (maps to --cache-copy-layers) which can improve cache performance for certain layer patterns. Default behavior is fine here; mentioning for awareness only.

SOP COMPLIANCE

Branch naming: Branch is kaniko-layer-cache -- does not follow {issue-number}-{kebab-case-purpose} convention. However, #106 is the PR itself (self-referencing via "Closes #106"), not a separate issue. No standalone issue exists for this work, so there is no issue number to prefix. Minor deviation.
PR body follows template: Has Summary, Changes, Test Plan, Review Checklist, Related Notes sections. Well-structured.
Related references plan slug: Related section references docs/infrastructure-and-pipeline.md and PR #91, but no plan slug from pal-e-docs. Acceptable for a small infra tweak.
No secrets committed: Credentials remain behind from_secret. The cache_repo value is an internal DNS name, not a secret.
No scope creep: Single file changed, 2 lines added, tightly scoped to the stated purpose.

PROCESS OBSERVATIONS

Deployment frequency: This change reduces build time, which directly supports higher deployment frequency (DORA metric). Good investment for a 2-line change.
Change failure risk: Low. Cache misconfiguration would at worst cause a build to fall back to uncached behavior (Kaniko gracefully degrades when cache is unavailable). It would not break the pipeline or produce incorrect images.
Documentation: PR body notes that docs/infrastructure-and-pipeline.md will be updated after confirming cache works. Issue #99/PR #100 appear to track pipeline docs updates separately -- good sequencing.
Verification plan: The test plan is solid -- it covers pipeline pass, Harbor repo creation, and cache hit confirmation on a subsequent build. All verification must happen post-merge since build-and-push only runs on main.

VERDICT: APPROVED

Clean, minimal, well-scoped CI change. No blockers. The cache configuration is correct for the existing Kaniko + Harbor setup. Risk is low with graceful degradation on cache miss.

## PR #106 Review ### DOMAIN REVIEW **Tech stack**: Woodpecker CI pipeline config (`.woodpecker.yaml`) with Kaniko Docker builder pushing to Harbor registry. The change is a 2-line addition to enable registry-based layer caching. **Kaniko cache configuration**: The two new settings are correct for the `woodpeckerci/plugin-kaniko` plugin: - `cache: true` enables Kaniko's `--cache=true` flag - `cache_repo` points to a dedicated cache repository within the same Harbor instance **Registry consistency**: The `cache_repo` uses `harbor.harbor.svc.cluster.local` which matches the `registry` and `insecure-registry` values already set on lines 62-64. This is the in-cluster service FQDN -- correct for a Woodpecker runner executing inside the same k8s cluster. **Insecure registry**: The cache repo is on the same `harbor.harbor.svc.cluster.local` host that is already listed under `insecure` and `insecure-registry`. Kaniko should inherit these settings for cache pulls/pushes. No additional insecure flags needed. **Layer caching effectiveness**: The Dockerfile is well-structured for caching -- `Gemfile` and `Gemfile.lock` are copied before `bundle install`, so the expensive dependency layer will be cached when only application code changes. The PR description's claim of ~2-3 min savings on unchanged Gemfile merges is plausible. **Multi-stage build note**: The Dockerfile uses a multi-stage build (`AS build` then a runtime stage). Kaniko handles multi-stage caching correctly with `--cache=true`, caching intermediate layers from all stages. No domain concerns. ### BLOCKERS None. This is a CI configuration change -- no application code, no user input, no auth logic, no secrets exposed. The `cache_repo` value is an internal cluster address, not a secret. Credentials remain sourced from `from_secret` references. No BLOCKER criteria are triggered. ### NITS 1. **Cache TTL not specified**: Kaniko supports `--cache-ttl` to control how long cached layers are retained. Without it, cached layers persist indefinitely in the Harbor cache repo. This is fine for now but worth considering if Harbor storage becomes a concern. Non-blocking. 2. **No `cache_copy_layers` setting**: The plugin supports `cache_copy_layers` (maps to `--cache-copy-layers`) which can improve cache performance for certain layer patterns. Default behavior is fine here; mentioning for awareness only. ### SOP COMPLIANCE - [ ] **Branch naming**: Branch is `kaniko-layer-cache` -- does not follow `{issue-number}-{kebab-case-purpose}` convention. However, #106 is the PR itself (self-referencing via "Closes #106"), not a separate issue. No standalone issue exists for this work, so there is no issue number to prefix. Minor deviation. - [x] **PR body follows template**: Has Summary, Changes, Test Plan, Review Checklist, Related Notes sections. Well-structured. - [ ] **Related references plan slug**: Related section references `docs/infrastructure-and-pipeline.md` and PR #91, but no plan slug from pal-e-docs. Acceptable for a small infra tweak. - [x] **No secrets committed**: Credentials remain behind `from_secret`. The `cache_repo` value is an internal DNS name, not a secret. - [x] **No scope creep**: Single file changed, 2 lines added, tightly scoped to the stated purpose. ### PROCESS OBSERVATIONS - **Deployment frequency**: This change reduces build time, which directly supports higher deployment frequency (DORA metric). Good investment for a 2-line change. - **Change failure risk**: Low. Cache misconfiguration would at worst cause a build to fall back to uncached behavior (Kaniko gracefully degrades when cache is unavailable). It would not break the pipeline or produce incorrect images. - **Documentation**: PR body notes that `docs/infrastructure-and-pipeline.md` will be updated after confirming cache works. Issue #99/PR #100 appear to track pipeline docs updates separately -- good sequencing. - **Verification plan**: The test plan is solid -- it covers pipeline pass, Harbor repo creation, and cache hit confirmation on a subsequent build. All verification must happen post-merge since `build-and-push` only runs on `main`. ### VERDICT: APPROVED Clean, minimal, well-scoped CI change. No blockers. The cache configuration is correct for the existing Kaniko + Harbor setup. Risk is low with graceful degradation on cache miss.