в репозитории сборки на ноде так показывает:
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, которую получится обойти одним из двух способов выше…