kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add doc cross links for large repositories

This commit is contained in:
Steve Azzopardi 2019-04-23 04:11:19 +00:00 committed by Evan Read
parent 46bdbc5d77
commit c117d7bb16
1 changed files with 20 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
doc/ci/large_repositories/index.md
View File

@ -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