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

Document GIT_STRATEGY=none 

[ci skip]
This commit is contained in:
Nick Thomas 2016-09-28 18:37:25 +01:00
parent bac56e3bf1
commit 15ff8dcb25
1 changed files with 26 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
doc/ci/yaml/README.md
View File

@ -858,27 +858,45 @@ job:
## Git Strategy
> Introduced in GitLab 8.9 as an experimental feature. May change in future
releases or be removed completely.
> Introduced in GitLab 8.9 as an experimental feature. May change or be removed
completely in future releases. `GIT_STRATEGY=none` requires GitLab Runner
v1.7+.
You can set the `GIT_STRATEGY` used for getting recent application code. `clone`
is slower, but makes sure you have a clean directory before every build. `fetch`
is faster. `GIT_STRATEGY` can be specified in the global `variables` section or
in the `variables` section for individual jobs. If it's not specified, then the
default from project settings will be used.
You can set the `GIT_STRATEGY` used for getting recent application code, either
in the global [`variables`](#variables) section or the [`variables`](#job-variables)
section for individual jobs. If left 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.
```
variables:
GIT_STRATEGY: clone
```
or
`fetch` is faster as it re-uses the project workspace (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.
```
variables:
GIT_STRATEGY: fetch
```
`none` also re-uses the project workspace, 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.
```
variables:
GIT_STRATEGY: none
```
## Shallow cloning
> Introduced in GitLab 8.9 as an experimental feature. May change in future