From 3d546c309490c23c4f4cf39f2df783cfa5475548 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Sun, 22 Nov 2020 18:09:29 +0000 Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master --- doc/ci/large_repositories/index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md index f25ef7c725a..dba0fedca7d 100644 --- a/doc/ci/large_repositories/index.md +++ b/doc/ci/large_repositories/index.md @@ -32,7 +32,7 @@ GitLab and GitLab Runner perform a [shallow clone](../pipelines/settings.md#git- by default. Ideally, you should always use `GIT_DEPTH` with a small number -like 10. This will instruct GitLab Runner to perform shallow clones. +like 10. This instructs GitLab Runner to perform shallow clones. Shallow clones make Git request only the latest set of changes for a given branch, up to desired number of commits as defined by the `GIT_DEPTH` variable. @@ -152,7 +152,7 @@ concurrent = 4 This `config.toml`: - Uses the `shell` executor, -- Specifies a custom `/builds` directory where all clones will be stored. +- Specifies a custom `/builds` directory where all clones are stored. - Enables the ability to specify `GIT_CLONE_PATH`, - Runs at most 4 jobs at once. @@ -177,7 +177,7 @@ concurrent = 4 This `config.toml`: - Uses the `docker` executor, -- Specifies a custom `/builds` directory on disk where all clones will be stored. +- Specifies a custom `/builds` directory on disk where all clones are stored. We host mount the `/builds` directory to make it reusable between subsequent runs and be allowed to override the cloning strategy. - Doesn't enable the ability to specify `GIT_CLONE_PATH` as it is enabled by default. @@ -187,7 +187,7 @@ This `config.toml`: Once we have the executor configured, we need to fine tune our `.gitlab-ci.yml`. -Our pipeline will be most performant if we use the following `.gitlab-ci.yml`: +Our pipeline is most performant if we use the following `.gitlab-ci.yml`: ```yaml variables: @@ -205,8 +205,8 @@ The above configures a: because we use the same clone path for all forks. Why use `$CI_CONCURRENT_ID`? The main reason is to ensure that worktrees used are not conflicting -between projects. The `$CI_CONCURRENT_ID` represents a unique identifier within the given executor, -so as long as we use it to construct the path, it is guaranteed that this directory will not conflict +between projects. The `$CI_CONCURRENT_ID` represents a unique identifier within the given executor. +When we use it to construct the path, this directory does not conflict with other concurrent jobs running. ### Store custom clone options in `config.toml` @@ -220,7 +220,7 @@ In such cases, it might be desirable to keep the `.gitlab-ci.yml` clone path agn a configuration of the runner. We can extend our [`config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html) -with the following specification that will be used by the runner if `.gitlab-ci.yml` will not override it: +with the following specification that is used by the runner if `.gitlab-ci.yml` does not override it: ```toml concurrent = 4