pal-e-docs

Review: Upgrade ruby-rails-build base image to Bundler 4.x

review-1578-2026-06-23 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- Standalone, discovered during paldocs sprint:1
  • [x] Repo -- listed as ldraney/pal-e-platform
  • [x] User Story -- present
  • [x] Context -- good explanation of Bundler 2.x vs 4.x checksum mismatch
  • [x] File Targets -- present (but WRONG, see below)
  • [x] Feature Flag -- none (correct for infra)
  • [x] Acceptance Criteria -- 4 items
  • [x] Test Expectations -- present
  • [x] Constraints -- present, good backward-compat note
  • [x] Checklist -- present
  • [x] Related -- present

Traceability

  • [ ] story:base-images -- NOT found on project-pal-e-platform user-stories table. No matching story key exists. The story label is novel and has no backing user story entry. [SCOPE] Create user story entry for story:base-images on project-pal-e-platform user-stories section, OR reclassify under an existing story like story:superuser-deploy (since CI base images directly enable the deploy pipeline).
  • [ ] arch:ci-cd -- no architecture note arch-ci-cd found in pal-e-docs. [SCOPE] Create architecture note arch-ci-cd for the CI/CD pipeline component, OR use a more specific label like arch:base-images with a corresponding note.
  • [x] Forgejo issue -- https://forgejo.tail5b443a.ts.net/ldraney/pal-e-platform/issues/462, open

File Targets

  • [ ] images/ruby-rails-build/Dockerfile -- ISSUE: path does NOT exist in pal-e-platform. The ruby-rails-build image is built from ldraney/base-images/Dockerfile (a separate repo). The pal-e-platform repo has an unrelated docker/ruby-arch/Dockerfile which builds a different image (pal-e/ruby-arch, Arch Linux based).
Actual file target: ldraney/base-images/Dockerfile -- this is the Dockerfile that produces library/ruby-rails-build:latest via the .woodpecker.yaml build-and-push-build step. Currently based on ruby:3.4.9-slim (Debian). Bundler is NOT explicitly pinned; it inherits whatever version ships with the Ruby Docker image.

Repo Placement

MISMATCH. The Forgejo issue is filed on ldraney/pal-e-platform but the actual Dockerfile to modify lives in ldraney/base-images. The issue should be moved to ldraney/base-images, or a new issue created there and this one closed with a cross-reference.

Dependencies

  • No blocking items found on the board. The only in_progress item is Phase 7 (Block-Structured Content Model), which is unrelated.
  • Downstream: 5+ Rails repos consume ruby-rails-build:latest -- paldocs, landscaping-assistant, palinks, westside-ror, rails-base, flightscanner, test-ruby. All must be tested after the image update.
  • The issue correctly notes paldocs#72 and paldocs#73 as the triggering context.

Acceptance Criteria

4 ACs, mostly verifiable:
  • AC1 (Bundler >= 4.0 in Dockerfile) -- verifiable by reading the Dockerfile, but the approach needs thought: the current Dockerfile does NOT pin bundler at all. The fix may be adding RUN gem install bundler -v '>=4.0' or switching to a Ruby image that ships Bundler 4.x natively.
  • AC2 (paldocs CI passes) -- verifiable via Woodpecker pipeline.
  • AC3 (Harbor image tagged) -- verifiable via Harbor registry check.
  • AC4 (paldocs lockfile restored) -- verifiable, but this is work in a DIFFERENT repo (paldocs), not base-images. Should be a separate follow-up ticket or noted as cross-repo work.
Missing: no AC for backward-compatibility verification with other Rails repos, despite Constraints section calling this out.

Blast Radius

HIGH. This is a shared base image consumed by at least 5 Rails applications (paldocs, landscaping-assistant, palinks, westside-ror, rails-base, flightscanner, test-ruby). Pushing a broken image to :latest would break ALL Rails CI pipelines simultaneously. The Constraints section correctly flags this but the ACs do not include verification steps for non-paldocs repos.

Decomposition Assessment

File count: 1 file in 1 repo (base-images/Dockerfile). ACs: 4 (but AC4 is cross-repo). Estimated agent time: under 5 minutes for the Dockerfile change itself. However, cross-repo validation (AC2, AC4) adds complexity. No decomposition needed if scoped to just the Dockerfile change, but the cross-repo ACs should be split out or documented as manual follow-up.

Recommendation

  • [BODY] Fix Repo field: ldraney/pal-e-platform to ldraney/base-images
  • [BODY] Fix File Targets: images/ruby-rails-build/Dockerfile to Dockerfile (root of base-images repo). Note that bundler is currently inherited from the Ruby base image, not explicitly installed.
  • [BODY] AC4 (paldocs lockfile restore) is cross-repo work -- either remove it from this ticket's ACs and create a follow-up paldocs issue, or note it as manual post-merge step.
  • [BODY] Add AC: "All Rails repos using ruby-rails-build:latest pass CI after image update" (backward-compat verification).
  • [SCOPE] Create user story entry story:base-images on project-pal-e-platform user-stories section, OR relabel to story:superuser-deploy.
  • [SCOPE] Create architecture note arch-ci-cd, OR relabel to a more specific component like arch:base-images with a backing note.
  • [LABEL] Move or re-file the Forgejo issue from ldraney/pal-e-platform to ldraney/base-images.