Gitlab runner 13.1.1 проверяет фиксацию, а не мою ветку - PullRequest
Новая
       139

Gitlab runner 13.1.1 проверяет фиксацию, а не мою ветку

0 голосов
/ 13 июля 2020

У меня есть файл .gitlab-ci.yml, который ранее запускался без проблем с Gitlab runner 12.9.0. Бегун был обновлен до 13.1.1, и теперь он больше не проверяет мою ветку 20-branchname, а вместо этого выполняет фиксацию. (вероятно, самый последний). Это означает, что исполнитель не может объединить ветвь с главной ветвью для выполнения проверки согласованности, потому что это приводит к fatal: refusing to merge unrelated histories. Я использую GitLab 13.2.0-pre

Когда у меня выполняется запуск git status, он печатает, что HEAD отсоединен. Я обнаружил эту разницу в необработанном журнале двух конвейеров с использованием разных версий бегуна:

12.9.0: 

[32;1mChecking out 16b0a39c as 20-branchname...[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: 

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

Вот как выглядит мой .gitlab-ci.yml: 

.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"

Я также пытался добавить git checkout 20-branchname в .gitlab-ci.yml, и хотя это приводит к git status, отображающему, что моя ветка была проверена а не фиксация, это все равно приводит к ошибке несвязанных историй при попытке слияния с мастером.

Кто-нибудь имеет представление о том, какая разница между Gitlab runner 12.9.0 и 13.1.1 может быть причиной? Любая помощь приветствуется!

1 Ответ

1 голос
/ 14 июля 2020

Оказывается, проблема была в глубине git. По умолчанию он был установлен на 50, и я недавно превысил 50 коммитов в своей ветке. Я решил это, добавив это к .gitlab-ci.yml: 

variables:
  GIT_DEPTH: full
...