Bug #8401
closed
package build results in changes to Gemfile.lock files in git repo
Description
Performing a full build (e.g. `./arvados-dev/jenkins/run-build-packages-all-targets.sh`) on a WORKSPACE that is a git working directory results in a dirty working directory after the build.
This appears to be because of changes that `bundle` makes to the `Gemfile.lock` files in the apps/workbench and services/api directories:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: apps/workbench/Gemfile.lock
modified: services/api/Gemfile.lock
It would be good if source-controlled files were not modified during the build (or possibly if they were cleaned up with a `git checkout` afterwards?).
Updated by Brett Smith about 10 years ago
This issue isn't limited to the package builds. Running bundle install can cause this, depending on the version of Bundler you have installed. You'll need to do this to do development or run tests, too.
This seems to be more of a Bundler issue. See, e.g., https://github.com/bundler/bundler/issues/3697 (which was closed WONTFIX)
Updated by Brett Smith about 10 years ago
Josh, what version of Bundler are you using? Upgrading to 1.10+ may make this issue go away: that's when Bundler started adding these sections, but it's a lot more careful about when it does it, apparently only doing so if it's making other changes to Gemfile.lock.
We can't encode this in Gemfile.lock itself, because Bundler is the thing that reads that file to determine Gem versions in the first place…
Updated by Peter Amstutz