Fix Kaniko layer cache miss on bundle install #153

Merged

ldraney merged 1 commit from 152-fix-kaniko-cache-bust into main

2026-06-07 04:21:36 +00:00

ldraney commented

2026-06-07 04:15:48 +00:00

Owner

Summary

The Dockerfile's COPY vendor/* ./vendor/ copied CI-installed gems into the build context, but bundle install uses $BUNDLE_PATH from the base image — the copied gems were never used and invalidated Kaniko's layer cache on every build
Removed the unused COPY line and added /vendor/bundle to .dockerignore as a safety net

Closes #152

Changes

Dockerfile: Removed COPY vendor/* ./vendor/ (line 7) — eliminates the cache-busting layer
.dockerignore: Added /vendor/bundle — prevents CI gems from entering the build context

Test Plan

Next main build shows "Using cached layer" for bundle install in Kaniko logs
CI tests pass
Deployed image functionally identical

Review Checklist

No force pushes
Branch follows naming convention (152-fix-kaniko-cache-bust)
Changes match issue scope exactly

Forgejo issue: #152

## Summary - The Dockerfile's `COPY vendor/* ./vendor/` copied CI-installed gems into the build context, but `bundle install` uses `$BUNDLE_PATH` from the base image — the copied gems were never used and invalidated Kaniko's layer cache on every build - Removed the unused COPY line and added `/vendor/bundle` to `.dockerignore` as a safety net Closes #152 ## Changes - `Dockerfile`: Removed `COPY vendor/* ./vendor/` (line 7) — eliminates the cache-busting layer - `.dockerignore`: Added `/vendor/bundle` — prevents CI gems from entering the build context ## Test Plan - [ ] Next main build shows "Using cached layer" for bundle install in Kaniko logs - [ ] CI tests pass - [ ] Deployed image functionally identical ## Review Checklist - [x] No force pushes - [x] Branch follows naming convention (`152-fix-kaniko-cache-bust`) - [x] Changes match issue scope exactly ## Related Notes - Forgejo issue: #152

ldraney added 1 commit

2026-06-07 04:15:48 +00:00

Fix Kaniko layer cache miss caused by CI vendor/bundle copy

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

411d24e109

The Dockerfile copied vendor/* into the build context, but `bundle install`
uses $BUNDLE_PATH from the base image — not ./vendor/bundle. The copied
CI gems were unused and invalidated Kaniko's layer cache on every build.

Remove the COPY vendor/* line and add /vendor/bundle to .dockerignore as
a safety net.

Closes #152

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

ldraney commented

2026-06-07 04:16:22 +00:00

Author

Owner

QA Review -- PR #153

Scope check: 2 files changed (Dockerfile, .dockerignore), 3 additions, 1 deletion. Changes match issue #152 exactly. No extraneous modifications.

Findings

Dockerfile -- COPY vendor/* ./vendor/ removal

Correct. The subsequent bundle install uses $BUNDLE_PATH from the base image, not ./vendor/bundle. The removed line copied CI-installed gems that were never used by the Docker build, and their changing contents invalidated Kaniko's layer cache on every pipeline run.
The remaining COPY Gemfile Gemfile.lock ./ before bundle install is the correct pattern -- Kaniko can now cache the bundle install layer when Gemfile/Gemfile.lock are unchanged.

.dockerignore -- /vendor/bundle addition

Correct safety net. The COPY . . on Dockerfile line 14 would otherwise pull CI gems into the build context. The .dockerignore entry prevents this even if someone removes the line or changes the Dockerfile structure later.
Comment is clear and explains the WHY.

No issues found

No dead code introduced
No missing dependencies -- bundle install handles gem installation from Gemfile.lock
Branch naming follows convention (152-fix-kaniko-cache-bust)
PR body has Closes #152 reference
Test plan is appropriate for an infrastructure change

VERDICT: APPROVE

## QA Review -- PR #153 **Scope check**: 2 files changed (Dockerfile, .dockerignore), 3 additions, 1 deletion. Changes match issue #152 exactly. No extraneous modifications. ### Findings **Dockerfile -- `COPY vendor/* ./vendor/` removal** - Correct. The subsequent `bundle install` uses `$BUNDLE_PATH` from the base image, not `./vendor/bundle`. The removed line copied CI-installed gems that were never used by the Docker build, and their changing contents invalidated Kaniko's layer cache on every pipeline run. - The remaining `COPY Gemfile Gemfile.lock ./` before `bundle install` is the correct pattern -- Kaniko can now cache the bundle install layer when Gemfile/Gemfile.lock are unchanged. **.dockerignore -- `/vendor/bundle` addition** - Correct safety net. The `COPY . .` on Dockerfile line 14 would otherwise pull CI gems into the build context. The `.dockerignore` entry prevents this even if someone removes the line or changes the Dockerfile structure later. - Comment is clear and explains the WHY. ### No issues found - No dead code introduced - No missing dependencies -- `bundle install` handles gem installation from Gemfile.lock - Branch naming follows convention (`152-fix-kaniko-cache-bust`) - PR body has `Closes #152` reference - Test plan is appropriate for an infrastructure change **VERDICT: APPROVE**