Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Léo-Paul Géneau
gitlab-ce
Commits
15ff8dcb
Commit
15ff8dcb
authored
Sep 28, 2016
by
Nick Thomas
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Document GIT_STRATEGY=none
[ci skip]
parent
bac56e3b
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
26 additions
and
8 deletions
+26
-8
doc/ci/yaml/README.md
doc/ci/yaml/README.md
+26
-8
No files found.
doc/ci/yaml/README.md
View file @
15ff8dcb
...
...
@@ -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, 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.
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.
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
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment