Testing: Faster gitaly component upgrade
What does this MR do?
When Gitaly is not on or ahead of the version required, it will need updating for the tests to be reliable. Currently this does remove the Gitaly repository and child directories.
This is not great as a lot of work needs redoing:
- Fetching the Git repository
- Obtaining and rebuilding libgit2
- Obtaining and rebuilding the Ruby gems (where not already present)
This process is time consuming and not required. The Gitaly Makefile is rugged enough to understand what to rebuild when. As such this change just tells the testing code that sets up Gitaly to keep the repository around.
Side effects of this change are limited. Nonetheless note that the
inital clone is a shallow one, at --depth=1. This means that the
git-fetch(1) done by GitLab::Taskhelpers#checkout_version creates
a slightly more CPU intensive clone on the server side as the content
negotiation is more expensive. Further, this change requires protocol
version 2 to be used for Git. This is enforced by setting the config,
which removes the dependency on the Git version. See also:
https://gitlab.com/gitlab-org/git/-/blob/48bf2fa8bad054d66bd79c6ba903c89c704201f7/t/t5516-fetch-push.sh#L1247-1267
Conformity
-
I have included a changelog entry, or it's not needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides.