What does this MR do?
I discovered that the
bundle install that's made during Gitaly's
scripts/gitaly-test-build) is using CE's
Gemfile, but since it's installing the gem under
tmp/tests/gitaly/ruby/vendor/bundle, the gems are re-installed from scratch (example: https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/48603700).
By setting the installation
--path for Gitaly's Ruby to
~/vendor, the gems are installed in the same directory as CE's ones (also note that most, if not all, of the gems used in Gitaly's Ruby are also used by CE), thus the install is blazing fast since the gems are already there.
Since we're passing a custom
--path, unused gems (from the point of view of Gitaly's Ruby
Gemfile) would be removed since we've set the
--clean option in GitLab's
bundle install (in
scripts/prepare_build.sh), thus we need to pass
The end result is that only
9 Gemfile dependencies, 61 gems now installed (https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/49169158), and that most of them are already installed by the first
bundle install performed in
scripts/prepare_build.sh. Compare this to the previous situation where all GitLab's gems
226 Gemfile dependencies, 418 gems now installed. were reinstalled from scratch (https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/48603700).
Also see gitaly!552 (closed) for some more background.
Why was this MR needed?
To reduce pipelines' duration!
Does this MR meet the acceptance criteria?
- Has been reviewed by Backend
- Conform by the merge request performance guides
- Conform by the style guides
- Squashed related commits together
Related to &25.