Thanks for the suggestion of adding a Git cache for a GitLab Runner. A similar mechanism already exists that allows control of the Git strategy with fetch on a local working copy which is faster, and clone if not yet existing. All benefits and limitations are documented [0].

To help prevent unneeded traffic when a new pipeline job is executed, GitLab Runner uses a shallow Git clone by default on GitLab.com SaaS that only pulls a limited set of Git commits from the current head instead of a full clone. [1]

There is a feature proposal [2] to add support for partial clone and sparse-checkout strategies that have been added in more recent Git versions. Recommend commenting/subscribing.

Please note that for GitLab.com SaaS Shared Runners, the traffic limits do not apply with mostly internal cloud traffic. [3]

[0] https://docs.gitlab.com/ee/ci/runners/configure_runners.html...

[1] https://docs.gitlab.com/ee/ci/large_repositories/#shallow-cl...

[2] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26631

[3] https://about.gitlab.com/pricing/#what-counts-towards-my-tra...