Слияние перед сборкой дженкинсов не удастся, но не должно

У меня есть настройки jenkins для создания всех ветвей функций в проекте, и до того, как сборка объединит их для "разработки", поскольку меня больше интересует, если результат сборки слияния, а не сама ветвь функции.

Кажется, что это работает, если ветвь функции основана на разработке HEAD, но если точка разветвления перед началом HEAD, тогда jenkins говорит: ERROR: Branch не подходит для интеграции, поскольку она не сливается чисто.

И это было бы хорошо, если бы был конфликт. Но конфликта нет. Я проверил слияние вручную в консоли, и слияние выполняется автоматически.

Также, если сравнивать ветку признаков и разрабатывать в atlassian stash, она также показывает чистый diff без каких-либо конфликтов.

Я потерялся. Почему дженкинс не может слить его?

Ответ 1

Я нашел это сам. Это произошло потому, что git на сервере jenkins не был настроен с именем автора/электронной почтой.

После настройки этого (под дополнительным поведением) решена проблема.

Ответ 2

У меня была такая же ошибка, когда она застревала, пытаясь построить предыдущую ветку SHA-1. Я удалил ветку, она все еще пыталась построить ветвь SHA-1 и провалилась так же. Я сконфигурировал git с именем автора/электронной почтой, как это было предложено, но все равно не удалось. Затем я удалил корневой каталог рабочего пространства Jenkins, и ошибка была изменена на "Не удалось проверить...". Затем я воссоздал ветку непосредственно от мастера, загрузил незначительные изменения и создал запрос на растяжение. Дженкинс правильно перестроил новую ветку и снова начал работать. В этом обсуждается проблема "Не удалось проверить": https://issues.jenkins-ci.org/browse/JENKINS-26748

Ответ 3

Я также обнаружил, что эта ошибка возникла, если Jenkins/ git был настроен для выполнения мелкого клонирования. Если вы являетесь мелким клонированием, вам необходимо отключить его:

снимите флажок "Мелкий клон" в разделе "Дополнительные действия → Расширенное поведение клонов" в конфигурации задания
зачеркните глубину неглубокого клона (или это было все еще мелкое клонирование, если бы здесь было какое-либо значение)
удалите любые рабочие пространства для этого задания, так как он не будет "не прославлять" клон, он должен будет повторно клонировать.

Ответ 4

У меня есть несколько проектов в Gitlab, которые используют jenkins, но иногда проект поднимет эту проблему. Поэтому я не думаю об этом, потому что git имя или адрес электронной почты.

Всегда, я git вытягиваю из восходящего потока, убедитесь, что локаль согласован с удаленным, затем git commit --amend (вы можете просто выйти, не нужно его редактировать) → git pull -0 > git push → start jenkins.