Giving more contexts on the https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1203 change.
The new behavior on the fetching refs instead of cloning repo happens under the following condition,
- GitLab Runner 11.9+
- GitLab CE/EE (Rails) 11.9+
Basically, GitLab CE/EE sends
refspecs parameter to GitLab Runner https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/presenters/ci/build_runner_presenter.rb#L34, this parameter is to used in GitLab Runners for fetching branch/tag refs from remote repository. This change was introduced because we wanted GitLab Rails side to leverage respecs in order for https://gitlab.com/gitlab-org/gitlab-ee/issues/7380 though, there should not be a big difference between
git clone $URL or
mkdir $REPO_DIR && git remote add origin $URL && git fetch +refs/heads/branch_name:refs/remotes/origin/branch_name. In fact, the new behavior has already run on our development project https://gitlab.com/gitlab-org/gitlab-ce/pipelines and has no issues so far.
Here is an example job log, when GitLab-Runner initializes a repository directory and fetches refs instead of
git clone commands.
Running with gitlab-runner 11.10.0~beta.1249.ga9b92ea5 (a9b92ea5)
on shinya-MS-7A34 LXxsZ3hC
Using Shell executor...
Running on shinya-MS-7A34...
Initialized empty Git repository in /home/shinya/workspace/thin-gdk/builds/LXxsZ3hC/0/root/job-run-test/.git/
Created fresh repository.
* [new branch] master -> origin/master
Checking out 3a894e28 as master...
Skipping Git submodules setup
$ echo 'a'
One thing that I’m seeing a similar situation in those reports is that everyone has encountered issues during deployments. So it might happen under a complicated situation. I’d appreciate if you’d help us to investigate this problem. Thanks.