In GitLab CI/CD, I have a job that merges the branch "development" into the branch "demo" on every change to "development". It worked perfectly fine for months, but suddenly it is failing due to merge conflicts. As this can of course happen, I wanted to resolve the conflicts locally. To my surprise, I found that there were no conflicts and the merge succeeded.
I am investigating this issue for three days now and of course I ensured that the latest commits of both branches are the exact same in CI and on my local machine when I am trying this. After I merged locally and pushed to "demo", the CI job succeeds once, just to fail with different conflicts on the next run.

The CI/CD job looks like this:

merge-development-into-demo:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'push' &&
          $CI_COMMIT_BRANCH == 'development'
  script:
    - git config --global user.email "$GITLAB_USER_EMAIL"
    - git config --global user.name "$GITLAB_USER_NAME"
    - git remote set-url origin "https://gitlab-ci-token:${CICD_JOBS_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git"
    - git fetch origin demo development
    - git show --no-patch origin/demo # Show the latest commit of "demo"
    - git show --no-patch origin/development # Show the latest commit of "development"
    - git checkout -b demo origin/demo
    - git merge --no-edit origin/development
    - git push

The job is using git 2.47.1 and I have 2.48.1 on my machine, so this should not be the reason.
What else could explain the issue?

In GitLab CI/CD, I have a job that merges the branch "development" into the branch "demo" on every change to "development". It worked perfectly fine for months, but suddenly it is failing due to merge conflicts. As this can of course happen, I wanted to resolve the conflicts locally. To my surprise, I found that there were no conflicts and the merge succeeded.
I am investigating this issue for three days now and of course I ensured that the latest commits of both branches are the exact same in CI and on my local machine when I am trying this. After I merged locally and pushed to "demo", the CI job succeeds once, just to fail with different conflicts on the next run.

The CI/CD job looks like this:

merge-development-into-demo:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'push' &&
          $CI_COMMIT_BRANCH == 'development'
  script:
    - git config --global user.email "$GITLAB_USER_EMAIL"
    - git config --global user.name "$GITLAB_USER_NAME"
    - git remote set-url origin "https://gitlab-ci-token:${CICD_JOBS_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git"
    - git fetch origin demo development
    - git show --no-patch origin/demo # Show the latest commit of "demo"
    - git show --no-patch origin/development # Show the latest commit of "development"
    - git checkout -b demo origin/demo
    - git merge --no-edit origin/development
    - git push

The job is using git 2.47.1 and I have 2.48.1 on my machine, so this should not be the reason.
What else could explain the issue?

• git
• gitlab-ci

• I'm pretty sure this is the answer, but please confirm and I'll type it up. I think if you print out the commit for demo instead of origin/demo you'll see the problem. The command git checkout -b demo origin/demo will fail if demo already exists, so it isn't resetting the demo branch. You need a capital -B there. – TTT Commented Jan 31 at 14:47
• (After further thought I'm slightly less confident that this is the fix, because this doesn't explain why it succeeds one time after you push it manually...) – TTT Commented Jan 31 at 14:50
• Thank you for your efforts! I posted the solution as answer. – halloei Commented Feb 3 at 13:00

1 Answer 1

It turned out that the fetched branches were actually shallow:
I mentioned that the CI/CD job worked for months, but it failed shortly after I changed the git depth in GitLab (Settings -> CI/CD -> General Pipelines -> Git shallow clone) from 50 to 5.
I don't know why this setting affects custom git fetch commands in the job's script section (I can't find an environment variable or a git config setting). But adding --unshallow solved the issue:

git fetch --unshallow origin demo development

Furthermore, the previous value of 50 is not that much, so I think the job should have failed earlier.