Make gem-bump-version inherit ruby/bundler versions
#7239
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 4, 2023
jeffwidman
changed the title
gem-bump-version inherit ruby/bundler versionsgem-bump-version inherit ruby/bundler versions
We need to inherit the bundler version used in `updater/Gemfile.lock` when running the `gem-bump-version` GitHub action. Otherwise when the action runs, `ruby/setup-ruby` will use a default `bundler` version, which will change `BUNDLED WITH` to this default version. Normally that wouldn't matter, but we also pin the version of `bundler` used in the native helper for the `bundler` ecosystem. And when we run the Updater in production at GitHub, since `BUNLDED WITH` is the last time we run `bundle install`, it'll change the bundler version not only for the `updater` app, but also for the native helper. So we'd be silently getting a different version of `bundler`, but only when running the `updater`, which means local debugging would see the pinned bundler version. Instead, let's avoid all that by ensuring we respect the version of `bundler` pinned in `Gemfile.lock`. By default, `setup/setup-ruby` looks for `Gemfile.lock` in the root directory, so the way to do that is set the working directory to `updater` so it looks for `updater/Gemfile.lock`. Unfortunately, that creates a new problem... `ruby/setup-ruby` looks for `.ruby-version` to find the Ruby version to run. Since we set the working directory to `updater`, it looks for `updater/.ruby-version`. And we don't want to move `.ruby-version` out of the root directory because that's where `rubocop` and other tooling such as IDE's look for it. Deivid pointed out that in the context of running this action, the version of Ruby really doesn't matter, since it's only used for the `bump-version.rb` script, which is very simple/generic. However, when I tried running the action, `ruby/setup-ruby` complained that it required a version of ruby to be specified. We don't want to have _yet-another-place_ to maintain the ruby version, so the way around that was to add a symlink: `cd updater && ln -s ../.ruby-version .ruby-version`. I tested this in another repo, and it worked successfully... the resulting PR used the version of `ruby` pinned in the root `.ruby-version` and the version of `bundler` pinned in `updater/Gemfile.lock`'s `BUNDLED WITH`.
jeffwidman
force-pushed
the
use-symlink-plus-working-directory-set-to-updater-for-bump-version
branch
from
f2f5e62
to
8c91e89
Compare
Closed
mctofu
approved these changes
May 4, 2023
jeffwidman
deleted the
use-symlink-plus-working-directory-set-to-updater-for-bump-version
branch
brettfo
pushed a commit
to brettfo/dependabot-core
that referenced
this pull request
Oct 11, 2023
…#7239) We need to inherit the bundler version used in `updater/Gemfile.lock` when running the `gem-bump-version` GitHub action. Otherwise when the action runs, `ruby/setup-ruby` will use a default `bundler` version, which will change `BUNDLED WITH` to this default version. Normally that wouldn't matter, but we also pin the version of `bundler` used in the native helper for the `bundler` ecosystem. And when we run the Updater in production at GitHub, since `BUNLDED WITH` is the last time we run `bundle install`, it'll change the bundler version not only for the `updater` app, but also for the native helper. So we'd be silently getting a different version of `bundler`, but only when running the `updater`, which means local debugging would see the pinned bundler version. Instead, let's avoid all that by ensuring we respect the version of `bundler` pinned in `Gemfile.lock`. By default, `setup/setup-ruby` looks for `Gemfile.lock` in the root directory, so the way to do that is set the working directory to `updater` so it looks for `updater/Gemfile.lock`. Unfortunately, that creates a new problem... `ruby/setup-ruby` looks for `.ruby-version` to find the Ruby version to run. Since we set the working directory to `updater`, it looks for `updater/.ruby-version`. And we don't want to move `.ruby-version` out of the root directory because that's where `rubocop` and other tooling such as IDE's look for it. Deivid pointed out that in the context of running this action, the version of Ruby really doesn't matter, since it's only used for the `bump-version.rb` script, which is very simple/generic. However, when I tried running the action, `ruby/setup-ruby` complained that it required a version of ruby to be specified. We don't want to have _yet-another-place_ to maintain the ruby version, so the way around that was to add a symlink: `cd updater && ln -s ../.ruby-version .ruby-version`. I tested this in another repo, and it worked successfully... the resulting PR used the version of `ruby` pinned in the root `.ruby-version` and the version of `bundler` pinned in `updater/Gemfile.lock`'s `BUNDLED WITH`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We need to inherit the bundler version used in
updater/Gemfile.lockwhen running thegem-bump-versionGitHub action.Otherwise when the action runs,
ruby/setup-rubywill use a defaultbundlerversion, which will changeBUNDLED WITHto this default version.Normally that wouldn't matter, but we also pin the version of
bundlerused in the native helper for thebundlerecosystem. And when we run the Updater in production at GitHub, sinceBUNLDED WITHis the last time we runbundle install, it'll change the bundler version not only for theupdaterapp, but also for the native helper. So we'd be silently getting a different version ofbundler, but only when running theupdater, which means local debugging would see the pinned bundler version.Instead, let's avoid all that by ensuring we respect the version of
bundlerpinned inGemfile.lock.By default,
setup/setup-rubylooks forGemfile.lockin the root directory, so the way to do that is set the working directory toupdaterso it looks forupdater/Gemfile.lock.Unfortunately, that creates a new problem...
ruby/setup-rubylooks for.ruby-versionto find the Ruby version to run. Since we set the working directory toupdater, it looks forupdater/.ruby-version. And we don't want to move.ruby-versionout of the root directory because that's whererubocopand other tooling such as IDE's look for it.Deivid pointed out that in the context of running this action, the version of Ruby really doesn't matter, since it's only used for the
bump-version.rbscript, which is very simple/generic. However, when I tried running the action,ruby/setup-rubycomplained that it required a version of ruby to be specified. We don't want to have yet-another-place to maintain the ruby version, so the way around that was to add a symlink:cd updater && ln -s ../.ruby-version .ruby-version.I tested this in another repo, and it worked successfully... the resulting PR used the version of
rubypinned in the root.ruby-versionand the version ofbundlerpinned inupdater/Gemfile.lock'sBUNDLED WITH.Related: