diff options
author | Steve Azzopardi <steveazz@outlook.com> | 2019-04-23 07:11:19 +0300 |
---|---|---|
committer | Evan Read <eread@gitlab.com> | 2019-04-23 07:11:19 +0300 |
commit | c117d7bb1615fe265883121adb3358f6fe9fc98f (patch) | |
tree | b28558249ce83027abca5a90f207038582fdac00 /doc/ci | |
parent | 46bdbc5d776a0438366426e0ef48911123311744 (diff) |
Add doc cross links for large repositories
Diffstat (limited to 'doc/ci')
-rw-r--r-- | doc/ci/large_repositories/index.md | 39 |
1 files changed, 21 insertions, 18 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. - -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. +[`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`](../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 |