summaryrefslogtreecommitdiff
path: root/doc/ci/large_repositories/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/ci/large_repositories/index.md')
-rw-r--r--doc/ci/large_repositories/index.md33
1 files changed, 10 insertions, 23 deletions
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md
index 0019eb5f40c..f25ef7c725a 100644
--- a/doc/ci/large_repositories/index.md
+++ b/doc/ci/large_repositories/index.md
@@ -56,29 +56,16 @@ test:
> Introduced in GitLab Runner 8.9.
-By default, GitLab is configured to always prefer the `GIT_STRATEGY: fetch` strategy.
-The `GIT_STRATEGY: fetch` strategy will re-use existing worktrees if found
-on disk. This is different to the `GIT_STRATEGY: clone` strategy
-as in case of clones, if a worktree is found, it is removed before clone.
-
-Usage of `fetch` is preferred because it reduces the amount of data to transfer and
+By default, GitLab is configured to use the [`fetch` Git strategy](../runners/README.md#git-strategy),
+which is recommended for large repositories.
+This strategy reduces the amount of data to transfer and
does not really impact the operations that you might do on a repository from CI.
-However, `fetch` does require access to the previous worktree. This works
-well when using the `shell` or `docker` executor because these
-try to preserve worktrees and try to re-use them by default.
-
-This does not work today for `kubernetes` executor and has limitations when using
-`docker+machine`. `kubernetes` executor today always clones into ephemeral directory.
-
-GitLab also offers the `GIT_STRATEGY: none` strategy. This disables any `fetch` and `checkout` commands
-done by GitLab, requiring you to do them.
-
## Git clone path
> Introduced in GitLab Runner 11.10.
-[`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) allows you to
+[`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) allows you to
control where you clone your sources. This can have implications if you
heavily use big repositories with fork workflow.
@@ -90,7 +77,7 @@ In such cases, ideally you want to make the GitLab Runner executor be used only
for the given project and not shared across different projects to make this
process more efficient.
-The [`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) has to be
+The [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) has to be
within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path
from disk.
@@ -98,12 +85,12 @@ from disk.
> Introduced in GitLab Runner 11.10.
-[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags) allows you to control
+[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) allows you to control
whether or not you require the `git clean` command to be executed for each CI
job. By default, GitLab ensures that you have your worktree on the given SHA,
and that your repository is clean.
-[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags) is disabled when set
+[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) is disabled when set
to `none`. On very big repositories, this might be desired because `git
clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
-e .build/` (for example) allows you to control and disable removal of some
@@ -112,7 +99,7 @@ the incremental builds. This has the biggest effect if you re-use existing
machines and have an existing worktree that you can re-use for builds.
For exact parameters accepted by
-[`GIT_CLEAN_FLAGS`](../yaml/README.md#git-clean-flags), see the documentation
+[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags), see the documentation
for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
are dependent on Git version.
@@ -120,14 +107,14 @@ are dependent on Git version.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
-[`GIT_FETCH_EXTRA_FLAGS`](../yaml/README.md#git-fetch-extra-flags) allows you
+[`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags) allows you
to modify `git fetch` behavior by passing extra flags.
For example, if your project contains a large number of tags that your CI jobs don't rely on,
you could add [`--no-tags`](https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---no-tags)
to the extra flags to make your fetches faster and more compact.
-See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../yaml/README.md#git-fetch-extra-flags)
+See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/README.md#git-fetch-extra-flags)
for more information.
## Fork-based workflow