With the recent effort to make the test suite free of memory leaks we now run a lot more of test suites with the leak-sanitizer enabled. While we were originally only executing around 23000 tests, we're now at 30000 tests. Naturally, this has a significant impact on the runtime of such a test run. Naturally, this impact can also be felt for our leak-checking CI jobs. While macOS used to be the slowest-executing job on GitLab CI with ~15 minutes of runtime, nowadays it is our leak checks which take around 45 to 55 minutes. Our Linux runners for GitLab CI are untagged, which means that they default to the "small" machine type with two CPU cores [1]. Upgrade these to the "medium" runner, which provide four CPU cores and which should thus provide a noticeable speedup. In theory, we could upgrade to an ever larger machine than that. The official mirror [2] has an Ultimate license, so we could get up to 128 cores. But anybody running a fork of the Git project without such a license wouldn't be able to use those beefier machines and thus their pipelines would fail. [1]: https://docs.gitlab.com/ee/ci/runners/hosted_runners/linux.html [2]: https://gitlab.com/git-scm/git/ Signed-off-by: Patrick Steinhardt <ps@xxxxxx> --- A test run can be found at [1]. This change decreases the runtime by about 20 minutes to 25 - 28 minutes in total. I'd be open to adjust this to use "large" runners, but as mentioned in the commit message that would cause problems when somebody hosts their own Git repository at GitLab. Is this something we care about? Patrick [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/215 .gitlab-ci.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 80b1668ebe..4abfbc3e20 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -9,6 +9,8 @@ workflow: test:linux: image: $image + tags: + - saas-linux-medium-amd64 variables: CUSTOM_PATH: "/custom" before_script: base-commit: 3fb745257b30a643ee78c9a7c52ab107c82e4745 -- 2.46.0.551.gc5ee8f2d1c.dirty
