-
Notifications
You must be signed in to change notification settings - Fork 372
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ruby): add Gemfile.Lock updater #1790
Conversation
Adds support for updating the ruby gem version in a committed Gemfile.lock file. This helps ensure that bundle install works correctly after a version.rb version change. There is also some additional logic introduced to simulate how ruby Gem::Version handles `-` with prerelease semvers (e.g. `1.0.0-alpha` is parsed as `1.0.0.pre.alpha). A future update could make use of the new common stringifyRubyVersion to translate the version into the more commonly used `.` prerelease seperatorwhich is treated "as is" and avoids the `.pre.` replacement of `-`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@chingor13 - Question. What is the typical cadence for releases of |
I think this PR just broke my CI for a Rails application. It's now automatically overwriting the first listed gem's version in Example from a release-please PR request in a Rails repo: # Gemfile.lock
- actioncable (7.0.4)
+ actioncable (0.0.1) Release please config: steps:
- uses: GoogleCloudPlatform/release-please-action@v3
id: release
with:
release-type: ruby
version-file: "version.rb"
bump-minor-pre-major: true # Gemfile.lock
GEM
remote: https://rubygems.org/
specs:
actioncable (7.0.4)
actionpack (= 7.0.4)
activesupport (= 7.0.4)
nio4r (~> 2.0)
websocket-driver (>= 0.6.1)
actionmailbox (7.0.4)
..... |
@kjellberg - Sorry to hear this. It looks like you haven't set a |
It looks like this is likely the problem. Putting together a PR to fix the issue. |
PR googleapis#1790 introduced support to update Gemfile.lock files. However this introduced an issue that updates random gem versions when the `package-name` (gemName) is not provided (which is optional). This fix ensures the gemName is valid before attempting to update the Gemfile.lock file.
Makes sense.. thanks :) |
PR #1790 introduced support to update Gemfile.lock files. However this introduced an issue that updates random gem versions when the `package-name` (gemName) is not provided (which is optional). This fix ensures the gemName is valid before attempting to update the Gemfile.lock file.
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #1768 🦕
Adds support for updating the ruby gem version in a committed Gemfile.lock file. This helps ensure that bundle install works correctly after a version.rb version change. There is also some additional logic introduced to simulate how ruby Gem::Version handles
-
with prerelease semvers (e.g.1.0.0-alpha
is parsed as `1.0.0.pre.alpha).A future update could make use of the new common stringifyRubyVersion to translate the version into the more commonly used
.
prerelease seperatorwhich is treated "as is" and avoids the.pre.
replacement of-
.