Fix conductor setup dirtying Pro lockfiles (sqlite3 Ruby 3.4 compat)#2667
Fix conductor setup dirtying Pro lockfiles (sqlite3 Ruby 3.4 compat)#2667
Conversation
bundle install resolves sqlite3 differently on Darwin 25 vs the platforms in the committed lockfiles, causing dirty diffs in react_on_rails_pro/ lockfiles. Restore them after install so workspaces start clean. Closes #2663 Co-Authored-By: Claude Opus 4.6 <[email protected]>
WalkthroughAdds per-directory Bundler-version matching and installation to the shell setup flow, driven by a new Changes
Sequence Diagram(s)sequenceDiagram
participant Script as conductor-setup.sh
participant FS as FileSystem
participant RubyGems as RubyGems/Bundler
participant Bundler as bundler (local)
Script->>FS: read LOCKFILE_DIRS
loop for each lockfile
Script->>FS: read <Gemfile.lock> BUNDLED WITH
Script->>Bundler: check installed versions
alt matching bundler missing
Script->>RubyGems: install specific bundler version
RubyGems-->>Bundler: bundler installed
end
Script->>FS: pushd directory
Script->>Bundler: run `bundle install`
Script->>FS: popd
end
Script->>Script: continue remaining setup (corepack, pnpm, hooks, lint)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR adds a Key observations:
Confidence Score: 3/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[bundle install - root] -->|may dirty| B[Gemfile.lock ❌ not restored]
C[bundle install - react_on_rails/spec/dummy] -->|may dirty| D[react_on_rails/spec/dummy/Gemfile.lock ❌ not restored]
E[bundle install - react_on_rails_pro] -->|may dirty| F[react_on_rails_pro/Gemfile.lock ✅ restored]
G[bundle install - react_on_rails_pro/spec/dummy] -->|may dirty| H[react_on_rails_pro/spec/dummy/Gemfile.lock ✅ restored]
F --> I[git checkout -- react_on_rails_pro lockfiles]
H --> I
I --> J[Workspace setup continues]
Last reviewed commit: "Restore committed Ge..." |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| git checkout -- \ | ||
| react_on_rails_pro/Gemfile.lock \ | ||
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | ||
| 2>/dev/null || true |
There was a problem hiding this comment.
react_on_rails/spec/dummy lockfiles are not restored
The script runs bundle install in four directories (root, react_on_rails/spec/dummy, react_on_rails_pro, and react_on_rails_pro/spec/dummy), but the new git checkout step only restores the two react_on_rails_pro lockfiles.
If the darwin-25 sqlite3 platform-resolution issue (or any other platform-specific gem resolution) affects the root Gemfile.lock or react_on_rails/spec/dummy/Gemfile.lock, those files will still be dirtied after setup. The fix feels incomplete — consider restoring all four lockfiles for consistency:
| git checkout -- \ | |
| react_on_rails_pro/Gemfile.lock \ | |
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | |
| 2>/dev/null || true | |
| git checkout -- \ | |
| Gemfile.lock \ | |
| react_on_rails/spec/dummy/Gemfile.lock \ | |
| react_on_rails_pro/Gemfile.lock \ | |
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | |
| 2>/dev/null || true |
If the root and react_on_rails/spec/dummy lockfiles are intentionally excluded (e.g., they don't pin sqlite3 and are therefore unaffected), a brief comment explaining that would make the intent clearer.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| git checkout -- \ | ||
| react_on_rails_pro/Gemfile.lock \ | ||
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | ||
| 2>/dev/null || true |
There was a problem hiding this comment.
The 2>/dev/null || true makes this best-effort, which is fine, but it silently discards both expected cases (file not tracked yet) and unexpected ones (git in a bad state, corrupted repo, etc.). Consider at least surfacing a warning when the checkout fails:
| git checkout -- \ | |
| react_on_rails_pro/Gemfile.lock \ | |
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | |
| 2>/dev/null || true | |
| git checkout -- \ | |
| react_on_rails_pro/Gemfile.lock \ | |
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | |
| 2>/dev/null || echo "⚠️ Could not restore lockfiles — workspace may be dirty" |
| git checkout -- \ | ||
| react_on_rails_pro/Gemfile.lock \ | ||
| react_on_rails_pro/spec/dummy/Gemfile.lock \ |
There was a problem hiding this comment.
The same platform-specific sqlite3 resolution issue could affect the root Gemfile.lock and react_on_rails/spec/dummy/Gemfile.lock as well — both were modified by bundle install earlier in the script. If the goal is a clean git status after setup, those should be restored here too for consistency:
| git checkout -- \ | |
| react_on_rails_pro/Gemfile.lock \ | |
| react_on_rails_pro/spec/dummy/Gemfile.lock \ | |
| git checkout -- \ | |
| Gemfile.lock \ | |
| react_on_rails/spec/dummy/Gemfile.lock \ | |
| react_on_rails_pro/Gemfile.lock \ | |
| react_on_rails_pro/spec/dummy/Gemfile.lock \ |
ReviewThe fix is straightforward and addresses a real pain point (platform-specific sqlite3 lockfile rewrites dirtying the workspace on macOS Sequoia). A couple of things worth addressing: Incomplete coverage — The script also runs Silent failure — Masking legitimate updates — Worth noting in a comment near the restore step: if a developer intentionally updates one of these lockfiles (e.g. adding a gem), running setup again will silently revert their changes. An alternative that avoids this entirely is using |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
conductor-setup.sh (1)
101-105: Consider extending this lockfile-stability pattern to post-setup workflows.
run_rspec:dummyand the Pro CI dummy install path also runbundle install, so they can reintroduce lockfile drift after setup. A follow-up centralization (or equivalent guard) would keep behavior consistent across developer and CI flows.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@conductor-setup.sh` around lines 101 - 105, The lockfile restore in conductor-setup.sh only runs during setup and can be undone by later bundle installs; update the post-setup workflows (specifically the run_rspec:dummy task and the Pro CI dummy install path) to reuse the same lockfile-stability guard: either call the existing restore routine from conductor-setup.sh or add equivalent git checkout commands for react_on_rails_pro/Gemfile.lock and react_on_rails_pro/spec/dummy/Gemfile.lock immediately before/after their bundle install steps so those flows cannot reintroduce lockfile drift.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@conductor-setup.sh`:
- Around line 101-105: The lockfile restore in conductor-setup.sh only runs
during setup and can be undone by later bundle installs; update the post-setup
workflows (specifically the run_rspec:dummy task and the Pro CI dummy install
path) to reuse the same lockfile-stability guard: either call the existing
restore routine from conductor-setup.sh or add equivalent git checkout commands
for react_on_rails_pro/Gemfile.lock and
react_on_rails_pro/spec/dummy/Gemfile.lock immediately before/after their bundle
install steps so those flows cannot reintroduce lockfile drift.
sqlite3 1.7.3 precompiled gems require ruby < 3.4.dev. On Ruby 3.4+, bundler silently falls back to the source gem variant, adding mini_portile2 and dirtying the lockfile on every bundle install. sqlite3 2.x precompiled gems support Ruby 3.4 natively, eliminating the platform resolution mismatch. Co-Authored-By: Claude Opus 4.6 <[email protected]>
justin808
changed the title
Read BUNDLED WITH from each lockfile and install that bundler version before running bundle install. Prevents bundler 4.x from re-resolving platform gems differently than the 2.x that created the lockfiles. Also consolidates the four bundle install blocks into a loop. Co-Authored-By: Claude Opus 4.6 <[email protected]>
| popd > /dev/null | ||
| for dir in "${LOCKFILE_DIRS[@]}"; do | ||
| echo " $dir ..." | ||
| pushd "$dir" > /dev/null |
There was a problem hiding this comment.
The bundle install loop does not guard against missing directories, unlike install_matching_bundler which skips when the lockfile is absent. If react_on_rails_pro or react_on_rails/spec/dummy do not exist (e.g. standalone OSS checkout), pushd will fail here and set -e will abort the whole setup.
| pushd "$dir" > /dev/null | |
| [[ -d "$dir" ]] || continue | |
| pushd "$dir" > /dev/null |
| local v | ||
| v=$(grep -A1 "BUNDLED WITH" "$lockfile" | tail -1 | tr -d ' ') | ||
| if [[ -n "$v" ]]; then | ||
| if ! run_cmd gem list bundler -i -v "$v" > /dev/null 2>&1; then |
There was a problem hiding this comment.
gem list -i -v VERSION is correct (exits 0 if that exact version is installed, 1 otherwise), but the flags read cryptically. A short comment here would help future readers understand what this check does without having to look up RubyGems docs.
| if ! run_cmd gem list bundler -i -v "$v" > /dev/null 2>&1; then | |
| # -i: exit 0 if installed, 1 if not; -v: scope to exact version | |
| if ! run_cmd gem list bundler -i -v "$v" > /dev/null 2>&1; then |
| install_matching_bundler() { | ||
| local lockfile="$1" | ||
| if [[ -f "$lockfile" ]]; then | ||
| local v |
There was a problem hiding this comment.
Minor robustness nit: tr -d ' ' strips ASCII spaces but not carriage returns. If a Gemfile.lock is ever checked in with CRLF line endings (Windows editor, etc.), the extracted version would be 2.4.10\r, which wouldn't match the gem list query and would trigger a redundant gem install on every run.
| local v | |
| v=$(grep -A1 "BUNDLED WITH" "$lockfile" | tail -1 | tr -d ' \r') |
| if [[ -f "$lockfile" ]]; then | ||
| local v | ||
| v=$(grep -A1 "BUNDLED WITH" "$lockfile" | tail -1 | tr -d ' ') | ||
| if [[ -n "$v" ]]; then |
There was a problem hiding this comment.
On older RubyGems versions, gem list without --exact does a substring/regex name match, so bundler could also match bundler-audit or similar gems. Adding --exact makes the intent explicit and safe across all RubyGems versions:
| if [[ -n "$v" ]]; then | |
| if ! run_cmd gem list --exact bundler -i -v "$v" > /dev/null 2>&1; then |
| } | ||
|
|
||
| LOCKFILE_DIRS=( | ||
| "." | ||
| "react_on_rails/spec/dummy" | ||
| "react_on_rails_pro" | ||
| "react_on_rails_pro/spec/dummy" |
There was a problem hiding this comment.
The react_on_rails_pro entries assume the Pro subpackage is present. Open-source contributors cloning only the public repo won't have these directories, and pushd react_on_rails_pro will cause the script to exit (due to set -e) with a confusing error.
This is a pre-existing issue (the old code had separate pushd react_on_rails_pro blocks), but consolidating into a shared array is a good moment to add a guard:
| } | |
| LOCKFILE_DIRS=( | |
| "." | |
| "react_on_rails/spec/dummy" | |
| "react_on_rails_pro" | |
| "react_on_rails_pro/spec/dummy" | |
| LOCKFILE_DIRS=( | |
| "." | |
| "react_on_rails/spec/dummy" | |
| ) | |
| # Add Pro directories only if they exist | |
| if [[ -d "react_on_rails_pro" ]]; then | |
| LOCKFILE_DIRS+=( | |
| "react_on_rails_pro" | |
| "react_on_rails_pro/spec/dummy" | |
| ) | |
| fi |
| @@ -470,14 +470,18 @@ GEM | |||
| actionpack (>= 6.1) | |||
| activesupport (>= 6.1) | |||
There was a problem hiding this comment.
The source gem entry (sqlite3 (2.9.2) with mini_portile2 dependency) still appears here alongside the native gems. This is expected — bundler keeps the source fallback in the lockfile even when a native gem is available — but it means on a platform without a matching native gem, bundler will still compile from source (requiring a C toolchain). Given that 2.x adds more native platforms (including musl variants), this should rarely be hit in practice.
|
Good PR. The root-cause fix (ensuring correct bundler version before install) is the right approach vs restoring lockfiles after the fact. The sqlite3 2.x bump correctly addresses Ruby 3.4 compat, and 2.9.2 lockfiles add musl platform variants which helps containerized CI. Minor issues flagged as inline comments: (1) tr needs backslash-r to guard against CRLF lockfiles; (2) gem list needs --exact to prevent substring matches; (3) LOCKFILE_DIRS hardcodes Pro directories without checking they exist - open-source contributors will hit a confusing pushd failure. No concerns with the sqlite3 2.x API surface (dev/test dep only) or run_cmd + pushd fallback behavior. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
conductor-setup.sh (1)
109-114: Consider explicitly pinning the Bundler version in the install command.The script already ensures the correct Bundler version is installed via
install_matching_bundler(), but you can make the version constraint explicit in the command itself. Instead of relying on the installed version, invokebundle _x.y.z_ installto guarantee the lockfile-specified version is used, eliminating any shim-resolution ambiguity across environments.♻️ Proposed change
for dir in "${LOCKFILE_DIRS[@]}"; do echo " $dir ..." pushd "$dir" > /dev/null - run_cmd bundle install + bundler_version=$(awk '/^BUNDLED WITH$/{getline; gsub(/[[:space:]]/,""); print; exit}' "$dir/Gemfile.lock") + if [[ -n "$bundler_version" ]]; then + run_cmd bundle _"$bundler_version"_ install + else + run_cmd bundle install + fi popd > /dev/null done🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@conductor-setup.sh` around lines 109 - 114, The loop currently runs run_cmd bundle install which can pick the wrong bundler shim; update it to invoke the explicit pinned bundler by using the installed version token (e.g., run_cmd "bundle _${BUNDLER_VERSION}_ install") and ensure the BUNDLER_VERSION is set by install_matching_bundler() before the loop; modify the invocation in the LOCKFILE_DIRS loop (where run_cmd is called) to use the bundle _x.y.z_ form so the lockfile-specified bundler is used consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@conductor-setup.sh`:
- Around line 109-114: The loop currently runs run_cmd bundle install which can
pick the wrong bundler shim; update it to invoke the explicit pinned bundler by
using the installed version token (e.g., run_cmd "bundle _${BUNDLER_VERSION}_
install") and ensure the BUNDLER_VERSION is set by install_matching_bundler()
before the loop; modify the invocation in the LOCKFILE_DIRS loop (where run_cmd
is called) to use the bundle _x.y.z_ form so the lockfile-specified bundler is
used consistently.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: df54fd07-41b8-4da1-a0f5-2b5c2bca05fd
⛔ Files ignored due to path filters (2)
react_on_rails_pro/Gemfile.lockis excluded by!**/*.lockreact_on_rails_pro/spec/dummy/Gemfile.lockis excluded by!**/*.lock
📒 Files selected for processing (2)
conductor-setup.shreact_on_rails_pro/Gemfile.development_dependencies
## Summary - Stamp `### [16.5.0.rc.0]` version header with today's date - Add 10 new changelog entries for PRs merged since v16.4.0 - Fix incomplete PR 2818 entry (missing author link) ### New entries added **Added:** - `create-react-on-rails-app --pro` support (PR 2818) - Global prerender env override `REACT_ON_RAILS_PRERENDER_OVERRIDE` (PR 2816) - `react_on_rails:sync_versions` rake task (PR 2797) - Pro/RSC setup checks in `react_on_rails:doctor` (PR 2674) **Changed:** - [Pro] Canonical env var for worker count is now `RENDERER_WORKERS_COUNT` (PR 2611) **Improved:** - Smoother `create-react-on-rails-app` and install generator flows (PR 2650) - Pro upgrade hint after install (PR 2642) **Fixed:** - Preserve runtime env vars across `Bundler.with_unbundled_env` (PR 2836) - Fix doctor prerender check and ExecJS display for Pro/RSC apps (PR 2773) - Fix doctor false positives for custom layouts (PR 2612) ### Skipped PRs (not user-visible) Docs-only: #2845, #2842, #2826, #2830, #2820, #2809, #2803, #2785, #2801, #2791, #2789, #2788, #2772, #2778, #2780, #2784, #2671, #2676, #2662, #2657, #2669 CI/internal tooling: #2825, #2817, #2819, #2812, #2815, #2810, #2808, #2807, #2634, #2798, #2761, #2760, #2658, #2639, #2667, #2656 ## Test plan - [x] Verified version header and diff links are correct - [x] Verified all entries follow changelog formatting conventions - [x] Verified file ends with newline - [ ] After merge, run `rake release` to publish 16.5.0.rc.0 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Documentation-only change updating `CHANGELOG.md` with a new `16.5.0.rc.0` section and compare links; no runtime code is modified. > > **Overview** > Adds a new `16.5.0.rc.0` (2026-03-25) section to `CHANGELOG.md`, consolidating recent PR entries under **Added/Changed/Improved/Fixed** and correcting the previously incomplete `--pro` CLI entry author attribution. > > Updates the bottom compare links so `[unreleased]` now compares from `v16.5.0.rc.0` and adds a link definition for `[16.5.0.rc.0]`. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 481a71c. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - v16.5.0.rc.0 * **New Features** * Added sync_versions task for streamlined version management * Expanded doctor checks for Pro and RSC support * **Improvements** * Enhanced generator workflow and Pro upgrade guidance * Improved environment variable handling and preservation * **Bug Fixes** * Fixed detection issues with doctor tools and ExecJS/prerender functionality <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
…2667) ## Summary - **Root cause**: `sqlite3 ~> 1.4` resolves to 1.7.3, whose precompiled gems require `ruby < 3.4.dev`. On Ruby 3.4.8, bundler falls back to the source gem variant (adding `mini_portile2`), dirtying both Pro lockfiles on every `bundle install` - **Fix**: Update `sqlite3` constraint from `~> 1.4` to `~> 2.0` — sqlite3 2.x precompiled gems support Ruby 3.4 natively - **Secondary**: Conductor setup script now ensures the correct bundler version (matching `BUNDLED WITH` in each lockfile) is installed before running `bundle install` Closes #2663 ## Test plan - [x] Pro unit tests pass (282 examples, 0 failures) with sqlite3 2.9.2 - [ ] Run `conductor-setup.sh` in a fresh workspace and verify `git status` shows no dirty lockfiles - [ ] CI passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches dependency resolution and lockfiles across multiple Ruby apps; risk is mainly around native gem compatibility and CI/environment differences when installing `sqlite3` 2.x and matching bundler versions. > > **Overview** > Prevents `conductor-setup.sh` from dirtying Ruby lockfiles by **auto-installing the Bundler version specified in each `Gemfile.lock`** and then running `bundle install` across all lockfile directories via a single loop. > > Updates React on Rails Pro development dependencies to require `sqlite3 ~> 2.0`, and refreshes the Pro and dummy app lockfiles to `sqlite3 2.9.2` with updated platform gem entries. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit bc76883. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Improved development setup with automatic synchronization of Bundler versions across project dependencies * Updated SQLite3 development dependency to version 2.0 <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 <[email protected]>
…2667) ## Summary - **Root cause**: `sqlite3 ~> 1.4` resolves to 1.7.3, whose precompiled gems require `ruby < 3.4.dev`. On Ruby 3.4.8, bundler falls back to the source gem variant (adding `mini_portile2`), dirtying both Pro lockfiles on every `bundle install` - **Fix**: Update `sqlite3` constraint from `~> 1.4` to `~> 2.0` — sqlite3 2.x precompiled gems support Ruby 3.4 natively - **Secondary**: Conductor setup script now ensures the correct bundler version (matching `BUNDLED WITH` in each lockfile) is installed before running `bundle install` Closes #2663 ## Test plan - [x] Pro unit tests pass (282 examples, 0 failures) with sqlite3 2.9.2 - [ ] Run `conductor-setup.sh` in a fresh workspace and verify `git status` shows no dirty lockfiles - [ ] CI passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches dependency resolution and lockfiles across multiple Ruby apps; risk is mainly around native gem compatibility and CI/environment differences when installing `sqlite3` 2.x and matching bundler versions. > > **Overview** > Prevents `conductor-setup.sh` from dirtying Ruby lockfiles by **auto-installing the Bundler version specified in each `Gemfile.lock`** and then running `bundle install` across all lockfile directories via a single loop. > > Updates React on Rails Pro development dependencies to require `sqlite3 ~> 2.0`, and refreshes the Pro and dummy app lockfiles to `sqlite3 2.9.2` with updated platform gem entries. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit bc76883. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Improved development setup with automatic synchronization of Bundler versions across project dependencies * Updated SQLite3 development dependency to version 2.0 <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 <[email protected]>
1 participant
Summary
sqlite3 ~> 1.4resolves to 1.7.3, whose precompiled gems requireruby < 3.4.dev. On Ruby 3.4.8, bundler falls back to the source gem variant (addingmini_portile2), dirtying both Pro lockfiles on everybundle installsqlite3constraint from~> 1.4to~> 2.0— sqlite3 2.x precompiled gems support Ruby 3.4 nativelyBUNDLED WITHin each lockfile) is installed before runningbundle installCloses #2663
Test plan
conductor-setup.shin a fresh workspace and verifygit statusshows no dirty lockfiles🤖 Generated with Claude Code
Note
Medium Risk
Touches dependency resolution and lockfiles across multiple Ruby apps; risk is mainly around native gem compatibility and CI/environment differences when installing
sqlite32.x and matching bundler versions.Overview
Prevents
conductor-setup.shfrom dirtying Ruby lockfiles by auto-installing the Bundler version specified in eachGemfile.lockand then runningbundle installacross all lockfile directories via a single loop.Updates React on Rails Pro development dependencies to require
sqlite3 ~> 2.0, and refreshes the Pro and dummy app lockfiles tosqlite3 2.9.2with updated platform gem entries.Written by Cursor Bugbot for commit bc76883. This will update automatically on new commits. Configure here.
Summary by CodeRabbit