From c117d7bb1615fe265883121adb3358f6fe9fc98f Mon Sep 17 00:00:00 2001 From: Steve Azzopardi Date: Tue, 23 Apr 2019 04:11:19 +0000 Subject: [PATCH] Add doc cross links for large repositories --- doc/ci/large_repositories/index.md | 37 ++++++++++++++++-------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md index cfe638c0a22..244ccbb92b0 100644 --- a/doc/ci/large_repositories/index.md +++ b/doc/ci/large_repositories/index.md @@ -72,8 +72,9 @@ done by GitLab, requiring you to do them. > Introduced in GitLab Runner 11.10. -`GIT_CLONE_PATH` allows you to control where you clone your sources. -This can have implications if you heavily use big repositories with fork workflow. +[`GIT_CLONE_PATH`](../yaml/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. Fork workflow from GitLab Runner's perspective is stored as a separate repository with separate worktree. That means that GitLab Runner cannot optimize the usage @@ -83,29 +84,31 @@ 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` has to be within the `$CI_BUILDS_DIR`. Currently, -it is impossible to pick any path from disk. +The [`GIT_CLONE_PATH`](../yaml/README.md#custom-build-directories) has to be +within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path +from disk. ## Git clean flags > Introduced in GitLab Runner 11.10. -`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, +[`GIT_CLEAN_FLAGS`](../yaml/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` 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 directories within the worktree between subsequent runs, -which can speed-up 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. +[`GIT_CLEAN_FLAGS`](../yaml/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 +directories within the worktree between subsequent runs, which can speed-up +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`, see the documentation -for [git clean](https://git-scm.com/docs/git-clean). The -available parameters are dependent on Git version. +For exact parameters accepted by +[`GIT_CLEAN_FLAGS`](../yaml/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. ## Fork-based workflow