diff options
author | Evan Read <eread@gitlab.com> | 2019-04-09 13:48:07 +0300 |
---|---|---|
committer | Achilleas Pipinellis <axil@gitlab.com> | 2019-04-09 13:48:07 +0300 |
commit | 163b6efb6a5857bb67c89161be721467a9ac338b (patch) | |
tree | f9c66373bf5b479fc9b6224a8869bcd2c8dce6c7 /doc/ci/large_repositories | |
parent | 629aa4cbe6914c598525386746658bc17b878cfd (diff) |
Use US English for content
Diffstat (limited to 'doc/ci/large_repositories')
-rw-r--r-- | doc/ci/large_repositories/index.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md index 576914e9dc3..cfe638c0a22 100644 --- a/doc/ci/large_repositories/index.md +++ b/doc/ci/large_repositories/index.md @@ -1,11 +1,11 @@ -# Optimising GitLab for large repositories +# Optimizing GitLab for large repositories Large repositories consisting of more than 50k files in a worktree often require special consideration because of the time required to clone and check out. GitLab and GitLab Runner handle this scenario well -but require optimised configuration to efficiently perform its +but require optimized configuration to efficiently perform its set of operations. The general guidelines for handling big repositories are simple. @@ -15,7 +15,7 @@ Each guideline is described in more detail in the sections below: - Always use shallow clone to reduce data transfer. Be aware that this puts more burden on GitLab instance due to higher CPU impact. - Control the clone directory if you heavily use a fork-based workflow. -- Optimise `git clean` flags to ensure that you remove or keep data that might affect or speed-up your build. +- Optimize `git clean` flags to ensure that you remove or keep data that might affect or speed-up your build. ## Shallow cloning @@ -76,7 +76,7 @@ done by GitLab, requiring you to do them. 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 optimise the usage +with separate worktree. That means that GitLab Runner cannot optimize the usage of worktrees and you might have to instruct GitLab Runner to use that. In such cases, ideally you want to make the GitLab Runner executor be used only used only @@ -113,7 +113,7 @@ available parameters are dependent on Git version. Following the guidelines above, lets imagine that we want to: -- Optimise for a big project (more than 50k files in directory). +- Optimize for a big project (more than 50k files in directory). - Use forks-based workflow for contributing. - Reuse existing worktrees. Have preconfigured runners that are pre-cloned with repositories. - Runner assigned only to project and all forks. |