diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index e969af10cfc91bf2ba27d6efad280d9d5db53633..f022012e2bcf38ab201eecdd302036208ef45045 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1246,8 +1246,8 @@ Read how caching works and find out some good practices in the [caching dependencies documentation](../caching/index.md). `cache` is used to specify a list of files and directories which should be -cached between jobs. You can only use paths that are within the project -workspace. +cached between jobs. You can only use paths that are within the local working +copy. If `cache` is defined outside the scope of jobs, it means it is set globally and all jobs will use that definition. @@ -1417,7 +1417,7 @@ be available for download in the GitLab UI. #### `artifacts:paths` -You can only use paths that are within the project workspace. +You can only use paths that are within the local working copy. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming)) patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match). To pass artifacts between different jobs, see [dependencies](#dependencies). @@ -2738,14 +2738,14 @@ unspecified, the default from project settings will be used. There are three possible values: `clone`, `fetch`, and `none`. `clone` is the slowest option. It clones the repository from scratch for every -job, ensuring that the project workspace is always pristine. +job, ensuring that the local working copy is always pristine. ```yaml variables: GIT_STRATEGY: clone ``` -`fetch` is faster as it re-uses the project workspace (falling back to `clone` +`fetch` is faster as it re-uses the local working copy (falling back to `clone` if it doesn't exist). `git clean` is used to undo any changes made by the last job, and `git fetch` is used to retrieve commits made since the last job ran. @@ -2754,11 +2754,11 @@ variables: GIT_STRATEGY: fetch ``` -`none` also re-uses the project workspace, but skips all Git operations +`none` also re-uses the local working copy, but skips all Git operations (including GitLab Runner's pre-clone script, if present). It is mostly useful for jobs that operate exclusively on artifacts (e.g., `deploy`). Git repository data may be present, but it is certain to be out of date, so you should only -rely on files brought into the project workspace from cache or artifacts. +rely on files brought into the local working copy from cache or artifacts. ```yaml variables: diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md index 26ea328c730a99af17e93d94a43313ba1aeaeddd..67051b801f0d7c0057c0d73182364ce56c3e1aa4 100644 --- a/doc/user/project/pipelines/settings.md +++ b/doc/user/project/pipelines/settings.md @@ -21,8 +21,8 @@ from GitLab in a job. There are two options. Using: - `git clone`, which is slower since it clones the repository from scratch - for every job, ensuring that the project workspace is always pristine. -- `git fetch`, which is faster as it re-uses the project workspace (falling + for every job, ensuring that the local working copy is always pristine. +- `git fetch`, which is faster as it re-uses the local working copy (falling back to clone if it doesn't exist). The default Git strategy can be overridden by the [GIT_STRATEGY variable](../../../ci/yaml/README.md#git-strategy)