Unable to opt out of new GIT_DEPTH behavior on merge request pipelines
Summary
As discussed in the comment thread from @redbaron1 in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25504#note_175224864, that MR introduced a change to the default GIT_DEPTH
strategy for checkouts related to merge request pipelines. This was done for several reasons: cost savings, shorter clone times (and more predictable), faster pipelines, and less egress traffic. It seemed like a good time to start testing that kind of change: very targeted, but still configurable.
This was one step on the way to introducing https://gitlab.com/gitlab-org/gitlab-ce/issues/59688, which would potentially introduce a change to GIT_DEPTH
globally.
Unfortunately, because this is changes the way clones work, it introduces a breaking change for git describe
in pipelines, and does not provide a settings/workaround to make it do full clones (the original behavior), instead of shallow. Setting GIT_DEPTH: 0
disables the behavior in certain scenarios, but must be done in every pipeline. To make matter worse there seem to be no good level to set GIT_DEPTH value to fix all broken pipelines:
- GIT_DEPTH on runner level seems to have no effect (overridden?) EDIT: checked, it is ignored.
GIT_DEPTH=0
inscript
section, but clone still happens with implicitGIT_DEPTH=10
- gitlab-ci.yml variables require all teams to make unplanned short notice changes AND PROPAGATE THEM TO ALL SCHEDULED/TRIGGERED JOBS, because not all of them run of master. There is going to be a long tail of broken builds discovered
- group-level variable override .gitlab-ci.yml values, so we cannot set it there, because some jobs already optimise clone and make use of
GIT_DEPTH
, breaking them is not a good way to move forward either
Steps to reproduce
(How one can reproduce the issue - this is very important)
Example Project
(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)
(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)
What is the current bug behavior?
(What actually happens)
What is the expected correct behavior?
(What you should see instead)
Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)
Output of checks
(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Possible fixes
In addition to updating 11.10 documentation with this breaking change, we should:
From @ayufan:
There's a feature flag that allows to go back to previous behavior: checking out on branch. I think we need to provide a way to have this overridden. (edited) I think that the best way would be to expose that as project setting: in place where we have
git clone/fetch
and add an option for shallow clone disabled for all exisiting, set to 10 for all new projects. seems a fairy straightforward change to make
This needs to be validated, but could be a solution.