Fix Kaniko layer cache miss on bundle install #152

New issue

Closed

opened 2026-06-07 04:14:25 +00:00 by ldraney · 0 comments

ldraney commented

2026-06-07 04:14:25 +00:00

Owner

Type

Bug

Lineage

Standalone — discovered during pipeline investigation (pipelines 327/328).

Repo

ldraney/landscaping-assistant

What Broke

Kaniko layer cache never hits for the RUN bundle install step. Every pipeline run rebuilds gems from scratch inside the Docker build (~2-3 min wasted). Pipeline logs show No cached layer found for cmd RUN bundle install on every build.

Root cause: COPY vendor/* ./vendor/ in the Dockerfile copies CI-installed gems from vendor/bundle into the build context. This changes the layer hash every run, invalidating the cache for everything after it. The copied gems aren't even used — the Dockerfile's bundle install installs to $BUNDLE_PATH (from the base image), not ./vendor/bundle.

Repro Steps

Push any commit to main
Watch Kaniko build-and-push step logs
Observe: No cached layer found for cmd RUN bundle install every time, even when Gemfile/Gemfile.lock unchanged

Expected Behavior

Kaniko should cache-hit on the RUN bundle install layer when Gemfile/Gemfile.lock haven't changed, showing Using cached layer in logs.

Environment

Cluster/namespace: prod (landscaping-assistant)
Woodpecker pipelines 327, 328
Kaniko plugin: woodpeckerci/plugin-kaniko:2.3.0

Acceptance Criteria

Next main pipeline with unchanged deps shows Using cached layer for bundle install
Final Docker image unchanged (same gems, same runtime behavior)
No regression in CI tests

landscaping-assistant project
Issue #60 — CI pipeline cache bundle install (prior optimization work)

### Type Bug ### Lineage Standalone — discovered during pipeline investigation (pipelines 327/328). ### Repo `ldraney/landscaping-assistant` ### What Broke Kaniko layer cache never hits for the `RUN bundle install` step. Every pipeline run rebuilds gems from scratch inside the Docker build (~2-3 min wasted). Pipeline logs show `No cached layer found for cmd RUN bundle install` on every build. Root cause: `COPY vendor/* ./vendor/` in the Dockerfile copies CI-installed gems from `vendor/bundle` into the build context. This changes the layer hash every run, invalidating the cache for everything after it. The copied gems aren't even used — the Dockerfile's `bundle install` installs to `$BUNDLE_PATH` (from the base image), not `./vendor/bundle`. ### Repro Steps 1. Push any commit to main 2. Watch Kaniko build-and-push step logs 3. Observe: `No cached layer found for cmd RUN bundle install` every time, even when Gemfile/Gemfile.lock unchanged ### Expected Behavior Kaniko should cache-hit on the `RUN bundle install` layer when Gemfile/Gemfile.lock haven't changed, showing `Using cached layer` in logs. ### Environment - Cluster/namespace: prod (landscaping-assistant) - Woodpecker pipelines 327, 328 - Kaniko plugin: woodpeckerci/plugin-kaniko:2.3.0 ### Acceptance Criteria - [ ] Next main pipeline with unchanged deps shows `Using cached layer` for bundle install - [ ] Final Docker image unchanged (same gems, same runtime behavior) - [ ] No regression in CI tests ### Related - `landscaping-assistant` project - Issue #60 — CI pipeline cache bundle install (prior optimization work)