GitSync поломался

#1

Доброе утро.

Сборка GitSync, которую сделал по книжке, перестала работать.
В логах пишет вот что:

From https://путь к репозиторию
10:58:20 * branch master -> FETCH_HEAD
10:58:21 ОТЛАДКА - в цикле
10:58:21 error: Your local changes to the following files would be overwritten by merge:
10:58:21 spec/tools/feature_gen_settings.json
10:58:21 Please commit your changes or stash them before you merge.
10:58:21 Aborting
10:58:21 ОТЛАДКА - РезультатРаботыПроцесса
10:58:21 -----
10:58:21 From https://путь к репозиторию
10:58:21 * branch master -> FETCH_HEAD
10:58:21 error: Your local changes to the following files would be overwritten by merge:
10:58:21 spec/tools/feature_gen_settings.json
10:58:21 Please commit your changes or stash them before you merge.
10:58:21 Aborting

В настройках сборки поставил “Clean before checkout”.
Удалял файл, на который ругается (spec/tools/feature_gen_settings.json) с коммитом в репозиторий.

Насколько я понял, gitsync получает последнее состояние репозитория, создает коммит по файлам из каталога src. Почему его смущает файл из другого каталога, особенно если в последнем состоянии его и нет, не пойму.

Подскажите куда копать и что это может быть?

#2

Команда git status в папке с репозиторием что показывает?

#3

в репозитории сборки на ноде так показывает:

HEAD detached at 54409ee24
nothing to commit, working tree clean

#4

Могу предположить, что хедер не в то место указывает.
git checkout master проделайте.

#5

54409ee24 это последний коммит, получается, что хедер указывает на него
git checkout master делаю в терминале в репозитории сборки, переключает на master,
не пойму, что это значит.
Сборка после перезапуска все равно приводит в состояние HEAD detached at 54409ee24

#6

Хорошо бы ещё разобраться, почему и в какой момент этот файл у вас появляется.

#7

Да, нужно посмотреть, правильно ли этот файл формируется.

Нужен ли он?

Можно перед гитсинком делать git reset --hard для сброса состояния репозитория и удаления изменений файлов

#8

Этот файл я сам создал в vscode, нужен для работы. Закоммитил в репозиторий как надо.
Сборка его скачала вместе со всем репозиторием.
Только почему-то git считает что есть не закрытые мержи по этому файлу.

#9

Придется видимо пересоздавать репозиторий в гитлабе
жаль история коммитов потеряется

#10

А у тебя гитсинк 2 или 3?

#11

gitsync@2.4.3

#12

Ну давайте по-рассуждаем.
Я в гитлабе удалил файл spec/tools/feature_gen_settings.json
удалил полностью каталог сборки
Сборка скачала репозиторий
Затем выполняет шаг gitsync
судя по логам, сам gitsync тоже сперва делает git pull
и вот после этого получает проблему, описанную выше
поскольку этот файл никто не успевает руками или программно изменить, значит сам репозитори “помнит” что-то про этот файл и считает, что он изменен. Какой-то хвост истории этого файла не закрыт.
Потому что, даже если его в репозитории уже нет, git считает, что он есть и изменен и последний коммит с удалением файла ничего не меняет.

Точечно почистить историю конкретного файла можно в git или нет?

#13

У тебя какой-то нестандартный файл.

Откуда он получается? кто его создает? какой-то доп.инструмент?

Подумай над этим сначала.

Перед вызовом гитсинк добавь в pipeline показ результата команды git status

Есть там этот файл?

#14

этот файл статический. Я его сам создал один раз и редактирую когда надо.
git status перед gitsync говорит, что коммитить нечего

11:35:23 J:\QA\jenkins_slave_2\workspace(c3) Gitsync>git status

11:35:24 HEAD detached at acfe08c42
11:35:24 nothing to commit, working tree clean

#15

Похоже, у тебя этот файл не под гитом в твоем локальном репозитории/рабочем каталоге.

А в удаленном репозитории, который является origin и к которому подключен гит и гитсинк, этот файл уже закоммичен.

Вот и получается, что гит пытается привезти тебе файл издалека, и выдает предупреждение, т.к. пулл этого файла может навредить и удалить твою версию, которая не под версионным контролем.

#16

Но ведь я полностью удаляю весь локальный репозиторий и сборка его издалека выкачивает.
то есть перед гитсинком этот файл скачан и соответствует удаленному репозиторию

#17

В качестве бреда - у тебя и Дженкинс и гитсинк используют один и тот же удаленный репозиторий Гит или разные?

#18

эммм. настраивал на один и тот же удаленный репозиторий.
я это проверю, конечно.
Работало до недавнего времени и сломалось вдруг.

#19

в репозитории сборки на ноде так показывает:

HEAD detached at 54409ee24
nothing to commit, working tree clean

Была аналогичная проблема. Проявлялась на более старой версии Jenkins чем 2.138.
Проблема была именно в том, как Jenkins работает репозиторием git. Посмотрите в выводе консоли задачи - выполняемые команды отображаются в самом начале.

Сначала вычисляется хэш, для которого потом будет выполняться чекаут

git.exe fetch --tags --progress E:/Databases/ci/pipeline +refs/heads/:refs/remotes/origin/
git.exe rev-parse “refs/remotes/origin/master^{commit}” # timeout=10
git.exe rev-parse “refs/remotes/origin/origin/master^{commit}” # timeout=10

Затем собственно выполняется чекаут, но не по имени ветки, а по хэшу:

git.exe checkout -f 03e989ffb0ac6f9c4afa39c8dafa8003674f44dd

Этот хэш отличался от того, на который на самом деле указывала ветка репозитория. Это приводило к ситуации detached HEAD.

В то время только начинал разбираться с Jenkins и списал происходящее на свое непонимание процесса. Обходил проблему насколько помню явным чекаутом ветки по имени в начале выполнения пайплайна. Команда pull перед этим насколько помню не требовалась.

Сейчас стоит Jenkins 2.138. Работает с репозиториями стабильно и хэш на который делается чекаут всегда совпадает с тем, на который ссылается ветка.

Тут правда еще один момент - репозиторий хранящий скрипты сборки и репозиторий хранилища конфигурации - это сейчас два разных репозитория. За первый отвечает разработчик, за второй всецело отвечает автоматика. Репозиторий конфигурации вытягивается через pull в подкаталог build рабочего каталога задачи сборки и этот каталог build указан в gitignore репозитория, хранящего скрипты сборки.

Репозиторий конфигурации в каталоге build никогда не вычищается. То есть никогда не выполняется git clone, выполняется только git pull. Потому что ждать пока склонируется репозиторий ERP означает неприемлемо увеличить время выполнения задачи сборки.

К сожалению не могу сейчас точно назвать причину ошибки и воспроизвести её. Есть только наблюдение, описанное выше. Попробуйте обойти проблему одним из способов:

  • Явно выполняя чекаут по имени ветки первым же шагом в пайплайне. В этом случае gitsync может продолжить делать выгрузку в рабочий каталог задачи сборки и репозиторий задачи сборки может быть одновременно и репозиторием конфигурации.
  • Разделить репозиторий задачи сборки и репозиторий хранилища конфигурации : вытягивать репозиотрий хранилища либо как подмодуль, либо как подкаталог указанный в gitignore репозитория задачи сборки.
  • Возможно поможет обновление Jenkins до более свежей версии? Хотя Вы написали, что до недавнего времени всё работало и репозиторий полностью вычищается перед клонированием и последующей работой gitsync. Возможно имеет место плавающая ошибка Jenkins, которую получится обойти одним из двух способов выше…
1 Симпатия
#20

Это не помогло.

Разделить репозиторий задачи сборки и репозиторий хранилища конфигурации : вытягивать репозиотрий хранилища либо как подмодуль, либо как подкаталог указанный в gitignore репозиторий задачи сборки

а вот это совсем не понимаю как сделать?
Репозиторий на гитлабе содержит и файлы конфигурации и все другие файлы проекта
Нужно разделить в гитлабе репозиторий на два репозитория?
И я не использую pipeline для задачи gitsync, скрипт который в самой сборке написан такой:

chcp 65001
git status
git checkout master
gitsync “K:\Хранилища конфигураций\Хранилище конфигурации С2” “https://путь к репозиторию.git” J:/QA/repo/src/cf -v8version 8.3.10.2466 -increment --storage-user “Кузнецов Максим” --storage-pwd 111

путь к репозиторию такой же как и в настройках сборки.
Сборка качает репозитория а гитсинк потом инкрементит /src/cf по данным из хранилища.