Gitlab runner 13.1.1 checks out a commit and not my branch

GitLab CI/CD
,
1

I have a .gitlab-ci.yml file that has previously run without issues with Gitlab runner 12.9.0.
The runner has been updated to 13.1.1 and now it no longer checks out to my branch 20-branchname, but instead a commit. (probably the most recent one) This means that the runner cannot merge the branch with the master branch to perform a coherence check because it results in fatal: refusing to merge unrelated histories

*When I have the runner execute git status it prints that HEAD is detached.
*I found this difference in the log raw of two pipelines using different versions of the runner:
12.9.0:

e[32;1mChecking out 16b0a39c as 20-branchname...e[0;m
From {repository url}
 * [new ref]         refs/pipelines/127602838 -> refs/pipelines/127602838
 * [new branch]      20-branchname             -> origin/20-branchname
git-lfs/2.8.0 (GitHub; windows amd64; go 1.12.2; git 30af66bb)

13.1.1:

e[32;1mChecking out 7410f5aa as 20-branchname...e[0;m
git-lfs/2.8.0 (GitHub; windows amd64; go 1.12.2; git 30af66bb)

*I am using the following versions

  • GitLab: 13.2.0-pre
  • Runner: 13.1.1

*This is how my .gitlab-ci.yml looks:

.shared_windows_runners:
  tags:
  - shared-windows
  - windows
  - windows-1809

stages:
  - test

# A few templates that help determine when to run a program
.template_manual_trigger_on_wip_merge_request:
  rules: &manual_trigger_on_wip_merge_request
    - if: '$CI_MERGE_REQUEST_TITLE =~ /WIP/'
      when: manual
      allow_failure: false
    - when: always
      allow_failure: false

.template_run_always:
  rules: &run_always
    - when: always
      allow_failure: false

# Check that the checked in target matches what is being generated.
Coherence Check:
  extends:
  - .shared_windows_runners
  stage: test
  rules: *manual_trigger_on_wip_merge_request
  before_script:
      # Git setup
    - git config --global user.email "runner@mail.com"
    - git config --global user.name "Runner name"
    - git config --global core.safecrlf false
    - git submodule sync
    - git submodule update --init
    - git status
    # Results in detached HEAD
  script:
    - git fetch origin
    - git merge origin/master -X ours -m "coherence check merge"
    # It fails here with "fatal: refusing to merge unrelated histories"

*I have also tried to add a git checkout 20-branchname in the .gitlab-ci.yml and while it does lead to git status displaying that my branch has been checked out and not the commit, it still results in the unrelated histories error when It tries to merge with master.

Does anyone have an idea of what difference between Gitlab runner 12.9.0 and 13.1.1 could be the cause?

2

The issue turned out to be the git depth, which was set to 50 by default. Since the issue emerged around my 50th commit, I set the git depth to “full” in my .gitlab-ci.yml and now it works.

1 Like
3

How to set git depth to “full”? By setting GIT_DEPTH=0?

4

The issue you’re facing seems to stem from the updated GitLab runner 13.1.1, which is now checking out a specific commit, causing a detached HEAD state. This can prevent your branch from merging with master due to Git recognizing them as unrelated histories. A possible solution is to explicitly check out the branch before attempting the merge by using git checkout origin/20-branchname. Additionally, you might need to modify your .gitlab-ci.yml to handle merging differently with the new runner version. If you’re still seeing the “unrelated histories” error, consider using --allow-unrelated-histories in the merge command. For more details on fixing detached HEAD issues, check out this guide.