Document `GIT_STRATEGY` and `GIT_DEPTH`
What does this MR do?
Documents GIT_STRATEGY
and GIT_DEPTH
. Also fixes the TOC since the anchors weren't working.
Are there points in the code the reviewer needs to double check?
The TOC and the location of the new entries.
Why was this MR needed?
What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/188
Screenshots (if relevant)
Merge request reports
Activity
Milestone changed to %8.9
mentioned in issue #18719 (closed)
I'm confused about the proposed documentation for
GIT_DEPTH
. It implies that setting it will cause submodules to be cloned shallowly, but in my experience,gitlab-ci-multi-runner
doesn't clone submodules at all (as its token that it uses for authentication is only good for the current project, not the other submodule projects). This would be a great feature; does the proposed language imply that the CI runner will clone recursively withGIT_DEPTH
set?@markpundsack @axil Note that this is an experimental feature, that should be later defined as a appropriate entry in
.gitlab-ci.yml
, and therefore we will need to update this documentation.GIT_DEPTH
only affects clonning of the main repository. We do not recursively clone submodules.Problems
-
Too small value for
GIT_DEPTH
can make it impossible to retry old changes. You will seeunresolved reference
in build log. We should then reconsider changingGIT_DEPTH
to higher value -
Builds that rely on
git describe
may not work correctly whenGIT_DEPTH
is set. This will happen, because only part of the git history is present on the build machine.
-
@markpundsack Also it would be good to notice that if
GIT_STRATEGY
is not present in.gitlab-ci.yml
(whether it would be a global or job-specific entry) then the default from project settings will be used. We can already set the strategy for entire project in Builds section of Project settings. Now we are introducing a feature to set this per job.@grzesiek I assume you mean that eventually we should have a
git:
section rather than use variables? If so, we could add a disclaimer about potentially removing or changing the functionality. Although I think calling it experimental implies that. :)@jasonroehm @ayufan My bad. If we're not doing submodules at all, then the note is irrelevant. I was just going by the git documentation.
I'll add the comments about old changes, etc. I think Travis has a good explanation where it's not just about retrying, but if you've queued up multiple builds, then any build that gets picked up that is old will fail if the ref isn't in the shallow clone. I was assuming we were cloning specific SHAs, but I guess that's not a thing. Shame.
@tmaczukin I already say "If specified, it will override the project settings in the web UI." but I guess that's not clear enough?
@markpundsack I was reading this three times and didn't notice this. The information is OK but maybe it would be good to write this as other notices in our documentation:
Notice: If specified, it will override the project settings in the web UI.
@tmaczukin yeah, I can see that. But when you put 3 notes next to each other, the information gets glossed over as well. Also, for that particular piece of information, I don't think it warrants use of a note. It's not really a warning anything dangerous.
How about this:
mentioned in issue #18906 (closed)
mentioned in commit 564026f6
mentioned in issue #18970 (closed)
mentioned in commit f81259d1
Mentioned in commit pfjason/gitlab-ce@564026f6
Mentioned in commit xhang/gitlab-ce@f81259d1
Mentioned in issue #18906 (closed)