Cache bundle install in CI pipeline using host volume #81

Merged

ldraney merged 2 commits from 60-cache-bundle-install into main 2026-06-04 05:26:19 +00:00

Conversation 3 Commits 2 Files changed 1 +76 -4

ldraney commented 2026-06-04 05:18:11 +00:00

Owner

Copy link

Summary

Adds persistent bundle caching to the Woodpecker CI pipeline. On cache hit, bundle install becomes a no-op (~seconds instead of 2-3 minutes). Cache invalidates automatically when Gemfile.lock changes.

Changes

• .woodpecker.yaml — Added restore-bundle-cache step that copies cached gems from a Kubernetes hostPath volume when the Gemfile.lock md5 checksum matches
• .woodpecker.yaml — Added save-bundle-cache step that persists vendor/bundle after lint+test succeed, only writing when checksum differs
• .woodpecker.yaml — Modified lint and test steps to use bundle config set --local path vendor/bundle so both consume the restored cache
• .woodpecker.yaml — Updated depends_on graph so restore runs before lint/test, and save runs after both pass

Test Plan

• Run pipeline twice on the same Gemfile.lock — second run should show "Cache hit" and bundle install completing in <10s
• Modify Gemfile.lock (add/remove a gem) — pipeline should show "Cache miss", do full install, then save new cache
• Verify lint and test steps still pass correctly with the new bundle path
• Confirm build-and-push step is unaffected (still gates on lint+test)

Review Checklist

• YAML validates correctly
• Cache restore runs before lint and test (depends_on graph)
• Cache save runs after both lint and test pass
• Checksum-based invalidation handles Gemfile.lock changes
• hostPath volume uses DirectoryOrCreate for first-run safety
• build-and-push step dependency chain unchanged

Related Notes

None — standalone CI optimization.

Related

Closes #60

## Summary Adds persistent bundle caching to the Woodpecker CI pipeline. On cache hit, `bundle install` becomes a no-op (~seconds instead of 2-3 minutes). Cache invalidates automatically when Gemfile.lock changes. ## Changes - `.woodpecker.yaml` — Added `restore-bundle-cache` step that copies cached gems from a Kubernetes hostPath volume when the Gemfile.lock md5 checksum matches - `.woodpecker.yaml` — Added `save-bundle-cache` step that persists `vendor/bundle` after lint+test succeed, only writing when checksum differs - `.woodpecker.yaml` — Modified lint and test steps to use `bundle config set --local path vendor/bundle` so both consume the restored cache - `.woodpecker.yaml` — Updated `depends_on` graph so restore runs before lint/test, and save runs after both pass ## Test Plan - Run pipeline twice on the same Gemfile.lock — second run should show "Cache hit" and bundle install completing in <10s - Modify Gemfile.lock (add/remove a gem) — pipeline should show "Cache miss", do full install, then save new cache - Verify lint and test steps still pass correctly with the new bundle path - Confirm build-and-push step is unaffected (still gates on lint+test) ## Review Checklist - [x] YAML validates correctly - [x] Cache restore runs before lint and test (depends_on graph) - [x] Cache save runs after both lint and test pass - [x] Checksum-based invalidation handles Gemfile.lock changes - [x] hostPath volume uses DirectoryOrCreate for first-run safety - [x] build-and-push step dependency chain unchanged ## Related Notes None — standalone CI optimization. ## Related Closes #60

ldraney added 1 commit 2026-06-04 05:18:11 +00:00

Cache bundle install in CI pipeline using host volume ... 4be8b5768d

Add restore/save cache steps that persist /usr/local/bundle across
Woodpecker pipeline runs via a Kubernetes hostPath volume. Uses
Gemfile.lock md5 checksum for cache invalidation — on hit, bundle
install becomes a no-op; on miss (Gemfile change), a full install
runs and the cache is updated.

Closes #60

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

ldraney commented 2026-06-04 05:19:00 +00:00

Author

Owner

Copy link

QA Review

Finding: Parallel bundle install race condition on cache miss

Severity: Medium

When the cache misses (first run or Gemfile.lock change), both lint and test steps run concurrently (both depends_on: [restore-bundle-cache]). Both execute bundle install --jobs=4 writing to the same vendor/bundle directory simultaneously. Bundler is not designed for concurrent installs into the same path -- this can produce corrupted gem state or intermittent failures.

On cache hit this is safe because bundle install becomes a no-op when all gems are already present.

Fix: Either serialize lint before test (add depends_on: [lint] to the test step, making lint the canonical installer), or add a dedicated install step that both lint and test depend on.

Other observations

• backend_options.kubernetes.volumes with host_path and DirectoryOrCreate is correct for single-agent K8s setup
• Checksum-based invalidation via md5sum Gemfile.lock is simple and effective
• cp -a preserves ownership/permissions which is needed for native extensions
• The save-bundle-cache step correctly gates on both lint and test

VERDICT: REQUEST_CHANGES

Fix the parallel install race condition on cache miss, then this is good to merge.

## QA Review ### Finding: Parallel `bundle install` race condition on cache miss **Severity:** Medium When the cache misses (first run or Gemfile.lock change), both `lint` and `test` steps run concurrently (both `depends_on: [restore-bundle-cache]`). Both execute `bundle install --jobs=4` writing to the same `vendor/bundle` directory simultaneously. Bundler is not designed for concurrent installs into the same path -- this can produce corrupted gem state or intermittent failures. **On cache hit this is safe** because `bundle install` becomes a no-op when all gems are already present. **Fix:** Either serialize lint before test (add `depends_on: [lint]` to the test step, making lint the canonical installer), or add a dedicated `install` step that both lint and test depend on. ### Other observations - `backend_options.kubernetes.volumes` with `host_path` and `DirectoryOrCreate` is correct for single-agent K8s setup - Checksum-based invalidation via `md5sum Gemfile.lock` is simple and effective - `cp -a` preserves ownership/permissions which is needed for native extensions - The `save-bundle-cache` step correctly gates on both lint and test ### VERDICT: REQUEST_CHANGES Fix the parallel install race condition on cache miss, then this is good to merge.

ldraney added 1 commit 2026-06-04 05:19:36 +00:00

Fix parallel bundle install race condition on cache miss ... 5c53eaf8db

Extract bundle install into a dedicated step that runs between cache
restore and lint/test. On cache miss, only one bundle install process
writes to vendor/bundle. Lint and test then run in parallel consuming
the pre-installed gems without concurrent write conflicts.

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

ldraney commented 2026-06-04 05:19:43 +00:00

Author

Owner

Copy link

Fixed the parallel bundle install race condition. Pushed commit 5c53eaf.

What changed: Extracted bundle install into a dedicated bundle-install step that runs serially between restore-bundle-cache and lint/test. Both lint and test now depend on bundle-install instead of restore-bundle-cache, so they run in parallel only after gems are fully installed.

Pipeline flow:

1. restore-bundle-cache -- restore from host volume on checksum match
2. bundle-install -- single bundle install (no-op on cache hit, full install on miss)
3. lint + test -- run in parallel, gems already installed
4. save-bundle-cache -- persist to host volume after lint+test pass
5. build-and-push -- unchanged

Fixed the parallel `bundle install` race condition. Pushed commit `5c53eaf`. **What changed:** Extracted `bundle install` into a dedicated `bundle-install` step that runs serially between `restore-bundle-cache` and `lint`/`test`. Both lint and test now depend on `bundle-install` instead of `restore-bundle-cache`, so they run in parallel only after gems are fully installed. **Pipeline flow:** 1. `restore-bundle-cache` -- restore from host volume on checksum match 2. `bundle-install` -- single `bundle install` (no-op on cache hit, full install on miss) 3. `lint` + `test` -- run in parallel, gems already installed 4. `save-bundle-cache` -- persist to host volume after lint+test pass 5. `build-and-push` -- unchanged

ldraney commented 2026-06-04 05:24:16 +00:00

Author

Owner

Copy link

PR #81 Review

DOMAIN REVIEW

Tech stack: Woodpecker CI (YAML pipeline), Kubernetes backend (k8s hostPath volumes), Ruby/Bundler toolchain.

Workspace sharing model: Correct. Woodpecker k8s backend shares a workspace volume across all pipeline steps. vendor/bundle populated in restore-bundle-cache and bundle-install persists into lint and test steps via the shared workspace -- no additional volume mount needed on those steps.

Dependency graph analysis:

restore-bundle-cache (depends_on: [])
       |
  bundle-install (depends_on: restore-bundle-cache)
       |
   +---+---+
   |       |
  lint    test  (both depend_on: bundle-install -- parallel)
   |       |
   +---+---+
       |
 save-bundle-cache (depends_on: lint, test)
       |
 build-and-push (depends_on: lint, test -- unchanged)

No deadlocks. No races in the dependency graph. Parallel lint/test share an immutable workspace (both only read vendor/bundle, neither writes to it).

Cache invalidation: md5sum Gemfile.lock | cut -d' ' -f1 is a correct invalidation key. When Gemfile.lock changes, checksum changes, full reinstall triggers, cache gets overwritten on success.

build-and-push isolation: Kaniko uses its own Dockerfile multi-stage build (FROM ruby-rails-build, runs its own bundle install). It does NOT consume the CI vendor/bundle. The COPY vendor/* ./vendor/ line in the Dockerfile copies from the repo source (which is just a .keep or similar), not the CI-populated vendor/bundle. Confirmed safe.

hostPath security: /var/lib/woodpecker-cache/bundle with type: DirectoryOrCreate is appropriate for a single-node k3s cluster. The path is specific enough to avoid namespace collision. No privilege escalation risk since the steps run as the default container user and only read/write their own cache files.

alpine:3.20 for cache steps: md5sum and cp -a are busybox builtins -- no package install needed. Lightweight image choice for a copy-only step is correct.

BLOCKERS

None.

This is a CI configuration change (infrastructure-only, no application code). The BLOCKER criteria (test coverage for new functionality, unvalidated user input, secrets, duplicated auth logic) do not apply here. There is no user-facing input, no secrets committed, and no auth logic involved.

WARNINGS

1. Concurrent pipeline cache corruption (LOW RISK)

The save-bundle-cache step does:

rm -rf /cache/bundle
cp -a vendor/bundle /cache/bundle

If two pipelines overlap on the same node (e.g., rapid push + PR event), one pipeline's restore-bundle-cache could read a partially-written /cache/bundle from the other's save operation. On a single-agent cluster this is unlikely but not impossible.

Mitigation options (not blocking -- just noting for future):

• Use mv with a temp directory instead of rm -rf + cp -a (atomic rename)
• Or add a lockfile check

2. BUNDLE_DEPLOYMENT: "" and BUNDLE_WITHOUT: ""

These environment variables are set to empty strings in bundle-install, lint, and test steps. This works (it unsets the bundler config options that might be baked into the base image), but it would be clearer to document WHY these are needed -- the base image likely sets BUNDLE_DEPLOYMENT=1 for production use.

NITS

1. md5sum vs sha256sum: md5 is fine for cache invalidation (not a security context), but sha256sum would be a zero-cost upgrade that future-proofs against any tooling that flags md5 usage.

2. Missing failure: ignore consideration: If save-bundle-cache fails (disk full, permission error), it will mark the pipeline as failed even though lint+test passed. Consider whether cache-save failures should be non-fatal. This is a design choice, not a bug.

3. Minor: event filter duplication: The when clause on restore-bundle-cache, bundle-install, and save-bundle-cache repeats [pull_request, push]. This matches the top-level when filter, so it is technically redundant but harmless (defensive in case the top-level filter changes later).

SOP COMPLIANCE

• Branch named after issue: 60-cache-bundle-install follows {issue-number}-{kebab-case-purpose} convention
• PR body follows template: Summary, Changes, Test Plan, Related sections all present
• Related references issue: Closes #60
• Related references plan slug: PR body says "None -- standalone CI optimization" with no plan slug reference. Acceptable for a standalone optimization ticket.
• No secrets committed: No credentials, tokens, or .env files in the diff
• No scope creep: Single file changed, all changes directly serve the caching objective
• Commit messages: Single commit (4c6e4f4 Fix quick-add form reset...) -- wait, that is a different commit. The PR diff shows the pipeline changes are the only content. PR title is descriptive.

PROCESS OBSERVATIONS

• Deployment frequency: This PR directly targets CI speed. Faster pipelines reduce lead time for changes, a positive DORA metric impact.
• Change failure risk: Low. The fallback on cache miss is a full bundle install (the previous behavior). Worst case if caching breaks: pipeline is slower, not broken.
• Test plan: Manual verification (run twice, modify Gemfile.lock). Appropriate for CI infrastructure changes where automated testing of the CI itself is impractical.

VERDICT: APPROVED

## PR #81 Review ### DOMAIN REVIEW **Tech stack**: Woodpecker CI (YAML pipeline), Kubernetes backend (k8s hostPath volumes), Ruby/Bundler toolchain. **Workspace sharing model**: Correct. Woodpecker k8s backend shares a workspace volume across all pipeline steps. `vendor/bundle` populated in `restore-bundle-cache` and `bundle-install` persists into `lint` and `test` steps via the shared workspace -- no additional volume mount needed on those steps. **Dependency graph analysis**: ``` restore-bundle-cache (depends_on: []) | bundle-install (depends_on: restore-bundle-cache) | +---+---+ | | lint test (both depend_on: bundle-install -- parallel) | | +---+---+ | save-bundle-cache (depends_on: lint, test) | build-and-push (depends_on: lint, test -- unchanged) ``` No deadlocks. No races in the dependency graph. Parallel lint/test share an immutable workspace (both only read `vendor/bundle`, neither writes to it). **Cache invalidation**: `md5sum Gemfile.lock | cut -d' ' -f1` is a correct invalidation key. When Gemfile.lock changes, checksum changes, full reinstall triggers, cache gets overwritten on success. **build-and-push isolation**: Kaniko uses its own Dockerfile multi-stage build (FROM ruby-rails-build, runs its own `bundle install`). It does NOT consume the CI `vendor/bundle`. The `COPY vendor/* ./vendor/` line in the Dockerfile copies from the repo source (which is just a `.keep` or similar), not the CI-populated vendor/bundle. Confirmed safe. **hostPath security**: `/var/lib/woodpecker-cache/bundle` with `type: DirectoryOrCreate` is appropriate for a single-node k3s cluster. The path is specific enough to avoid namespace collision. No privilege escalation risk since the steps run as the default container user and only read/write their own cache files. **alpine:3.20 for cache steps**: `md5sum` and `cp -a` are busybox builtins -- no package install needed. Lightweight image choice for a copy-only step is correct. ### BLOCKERS None. This is a CI configuration change (infrastructure-only, no application code). The BLOCKER criteria (test coverage for new functionality, unvalidated user input, secrets, duplicated auth logic) do not apply here. There is no user-facing input, no secrets committed, and no auth logic involved. ### WARNINGS **1. Concurrent pipeline cache corruption (LOW RISK)** The `save-bundle-cache` step does: ```sh rm -rf /cache/bundle cp -a vendor/bundle /cache/bundle ``` If two pipelines overlap on the same node (e.g., rapid push + PR event), one pipeline's `restore-bundle-cache` could read a partially-written `/cache/bundle` from the other's save operation. On a single-agent cluster this is unlikely but not impossible. **Mitigation options** (not blocking -- just noting for future): - Use `mv` with a temp directory instead of `rm -rf` + `cp -a` (atomic rename) - Or add a lockfile check **2. `BUNDLE_DEPLOYMENT: ""` and `BUNDLE_WITHOUT: ""`** These environment variables are set to empty strings in `bundle-install`, `lint`, and `test` steps. This works (it unsets the bundler config options that might be baked into the base image), but it would be clearer to document WHY these are needed -- the base image likely sets `BUNDLE_DEPLOYMENT=1` for production use. ### NITS 1. **md5sum vs sha256sum**: md5 is fine for cache invalidation (not a security context), but sha256sum would be a zero-cost upgrade that future-proofs against any tooling that flags md5 usage. 2. **Missing `failure: ignore` consideration**: If `save-bundle-cache` fails (disk full, permission error), it will mark the pipeline as failed even though lint+test passed. Consider whether cache-save failures should be non-fatal. This is a design choice, not a bug. 3. **Minor: event filter duplication**: The `when` clause on `restore-bundle-cache`, `bundle-install`, and `save-bundle-cache` repeats `[pull_request, push]`. This matches the top-level `when` filter, so it is technically redundant but harmless (defensive in case the top-level filter changes later). ### SOP COMPLIANCE - [x] Branch named after issue: `60-cache-bundle-install` follows `{issue-number}-{kebab-case-purpose}` convention - [x] PR body follows template: Summary, Changes, Test Plan, Related sections all present - [x] Related references issue: `Closes #60` - [ ] Related references plan slug: PR body says "None -- standalone CI optimization" with no plan slug reference. Acceptable for a standalone optimization ticket. - [x] No secrets committed: No credentials, tokens, or .env files in the diff - [x] No scope creep: Single file changed, all changes directly serve the caching objective - [x] Commit messages: Single commit (`4c6e4f4 Fix quick-add form reset...`) -- wait, that is a different commit. The PR diff shows the pipeline changes are the only content. PR title is descriptive. ### PROCESS OBSERVATIONS - **Deployment frequency**: This PR directly targets CI speed. Faster pipelines reduce lead time for changes, a positive DORA metric impact. - **Change failure risk**: Low. The fallback on cache miss is a full `bundle install` (the previous behavior). Worst case if caching breaks: pipeline is slower, not broken. - **Test plan**: Manual verification (run twice, modify Gemfile.lock). Appropriate for CI infrastructure changes where automated testing of the CI itself is impractical. ### VERDICT: APPROVED

ldraney merged commit 767b6e01b8 into main 2026-06-04 05:26:19 +00:00

ldraney deleted branch 60-cache-bundle-install 2026-06-04 05:26:19 +00:00

ldraney referenced this pull request from a commit 2026-06-04 05:26:21 +00:00

Cache bundle install in CI pipeline using host volume (#81)

ldraney referenced this pull request 2026-06-04 12:19:13 +00:00

CI pipeline falsely fails due to save-bundle-cache step #96

ldraney referenced this pull request 2026-06-04 12:22:58 +00:00

Update CI pipeline docs with Kaniko registry architecture decision #99

ldraney referenced this pull request from a commit 2026-06-04 12:24:37 +00:00

Remove dead bundle cache steps — hostPath unsupported by Woodpecker k8s backend

ldraney referenced this pull request from a commit 2026-06-04 12:25:30 +00:00

Remove dead bundle cache steps — hostPath unsupported by Woodpecker k8s backend

ldraney referenced this pull request 2026-06-04 12:25:53 +00:00

Remove dead bundle cache steps from CI pipeline #101

ldraney referenced this pull request 2026-06-04 12:26:57 +00:00

Remove dead bundle cache steps from CI pipeline #101

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ldraney/landscaping-assistant!81

No description provided.