Repository navigation
Sync Gemfile.lock PATH pin on version bump - #68
Conversation
The auto-release workflow bumps lib/pinot/version.rb via bin/bump-version but never updated Gemfile.lock's PATH gem pin. Since pinot.gemspec reads Pinot::VERSION, every bump left the lockfile's pinot-client pin stale, so `bundle install --frozen` (deployment installs) failed with "the gemspecs for path gems changed". Plain `bundle install` silently rewrites the pin, masking the drift, so it recurred on each release. - bin/bump-version: sync the Gemfile.lock PATH pin after writing version.rb (bundle lock --local, with a sed fallback when Bundler is unavailable) - auto-release-minor.yml: stage Gemfile.lock alongside version.rb in the release commit so the synced lock is committed - Gemfile.lock: fix the current drift (1.29.0 -> 1.44.0) Validated: frozen install now succeeds; unit tests 524 ex / 0 failures, coverage 99.72%; RuboCop clean; bundle-audit clean.
Code Health Review✅ Passed Existing debt (10)
Reviewed |
PR Readiness Review✅ Passed Reviewed |
Code Review✅ Passed Reviewed |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #68 +/- ##
=======================================
Coverage 99.72% 99.72%
=======================================
Files 27 27
Lines 1103 1103
=======================================
Hits 1100 1100
Misses 3 3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Addresses review findings on the version-bump lockfile sync: - release.yml (manual release) now stages Gemfile.lock alongside version.rb, matching auto-release-minor.yml. Previously a manual release recreated the PATH-pin drift because it committed only version.rb while still publishing the gem. - bin/bump-version: preserve the committed 'BUNDLED WITH' Bundler pin after 'bundle lock --local' so the release commit carries no unrelated Bundler-version churn. - bin/bump-version: normalize the version through RubyGems and loosen the fallback regex so prerelease versions (e.g. 1.5.0-rc1 -> 1.5.0.pre.rc1) produce a valid, matching lockfile pin.
The restore substitution assumed 3-space indentation but Bundler writes the BUNDLED WITH value with 2 spaces, so the restore was a silent no-op whenever 'bundle lock --local' actually rewrote the Bundler version (i.e. when CI's installed Bundler differs from the committed pin). Capture the full original value line and restore it verbatim via awk, independent of indentation width, so the release commit never carries an unrelated Bundler-version bump.
|
Addressed the three automated code-review findings and a follow-up found in independent review. Current head: Code-review findings (on
Independent review follow-up: the first restore attempt used a 3-space sed pattern while Bundler indents the value with 2 spaces, making the restore a silent no-op whenever CI's Bundler differed from the committed pin. Replaced with an awk pass that captures the full original value line and restores it verbatim regardless of indentation. Verified end-to-end: forcing a differing committed Validation on
Note: because this changes |
Summary
The auto-release workflow bumps
lib/pinot/version.rbon every push tomainbut never updatedGemfile.lock's PATH gem pin. Becausepinot.gemspecreadsPinot::VERSION, each bump changed the path gem's version while the lockfile'spinot-clientpin stayed stale (1.29.0vs. gemspec1.44.0).This is the durable fix for the recurring drift that #67 patched one line at a time — it repairs the owning bump step so the mismatch cannot reappear, validates against a frozen install, and covers both release paths.
Why it matters
Plain
bundle install(what CI uses) silently rewrites the lockfile to match, masking the drift. A frozen/deployment install surfaces it:Since
bin/bump-versiononly touchedversion.rb, the drift reappeared on every release. PR #67's one-line edit fixed the symptom once; the next release recreated it.Change
bin/bump-version— after writingversion.rb, sync theGemfile.lockPATH pin. Prefersbundle lock --local(canonical lockfile); falls back to a targeted, anchored in-place edit when Bundler is unavailable.BUNDLED WITHBundler pin afterbundle lock, so the release commit carries no unrelated Bundler-version churn.1.5.0-rc1→1.5.0.pre.rc1) produce a valid, matching lockfile pin..github/workflows/auto-release-minor.yml— the release commit now stagesGemfile.lockalongsideversion.rb..github/workflows/release.yml— the manual-release commit step likewise stagesGemfile.lock, so manual releases don't recreate the drift.Gemfile.lock— fixes the current drift (1.29.0→1.44.0); the only line that changes.No runtime/API behavior changes. The lockfile edit is pure metadata; the rest is release-tooling.
Validation (local, source @ this branch, Ruby 3.4.11)
BUNDLE_FROZEN=true bundle install→ success (was failing on committed source)bin/bump-version 1.45.0): version.rb + lockfile pin move together;BUNDLED WITHpreserved (4.0.8, not rewritten to local 4.0.21); lockfile diff is exactly one line; idempotent; frozen install succeedsCOVERAGE_MIN=95 bundle exec rspec spec/pinot/) → 524 examples, 0 failures, 1 pending; coverage 99.72% (≥95%)bundle exec rubocop lib/ spec/) → cleanbundle exec bundle-audit check→ no vulnerabilitiesbash -n bin/bump-version→ OKReview findings addressed
release.ymlcommitted onlyversion.rb: fixed (now stagesGemfile.lock).bundle lockrewritingBUNDLED WITH: fixed (pin preserved).Supersedes
Closes out the drift that #67 addressed; #67 can be closed in favor of this once reviewed/merged.