Как заставить Jenkins видеть слияние Git в качестве изменения?

Пользователи A и B каждый вносят изменения (в разных ветвях функций) в определенное репо.

Пользователь A объединяет изменения в промежуточную ветку. Дженкинс строит промежуточную ветку и преуспевает.

Пользователь C (менеджер выпуска для команды User B) объединяет изменения пользовательских Bs в промежуточную ветку. Однако что-то в слиянии идет не так и не замечается, например, конфликт, который не был правильно разрешен.

Дженкинс строит промежуточную ветку и терпит неудачу из-за плохого слияния.

Пользователи A и B уведомляются о сбое сборки, потому что их код был частью слияния, хотя их изменения не были виноваты. Пользователь C никогда не получает уведомление об отказе, хотя его плохое слияние было тем, что сломало сборку.

Есть ли способ:

  • Причина Дженкинс для обработки слияния совершает изменения? (Существует реальная возможность того, что код действительно будет изменен во время слияния!)
  • Уведомлять пользователя C (как коммиттер слияния) вместе с пользователями A и B?

Мы используем Git и Email-ext плагины для Дженкинса.

Изменить, несколько месяцев спустя: У вас все еще есть проблемы с этим - даже в сценарии, когда человек, который сделал слияние, не вносил изменений, было бы неплохо, если бы они были уведомлены о том, что сборка выполнена успешно (или не удалась).

Ответы

Ответ 1

Вы можете всегда пытаться принудительно не сглаживать быстрые переходы (опция --no-ff), и все слияния производят даже объединение слиянием (не только тогда, когда есть конфликты).

Он также создает более читаемый и понятный журнал git.

Кстати, если у вас есть последняя версия Jenkins Git плагин (они issues в прошлом).

Ответ 2

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

Если пользователь A и пользователь B вносят изменения, которые должны быть в конечном итоге объединены, то после объединения ваша история git должна показать вам SHA для изменений userA и userB.

Если я проверяю историю после того, как userC объединил изменения UserB, то я действительно не хочу видеть добавленную команду git, сообщающую мне, что userC объединил команду userB - последняя уже присутствует в git история.

И если слияние пользователяC регистрируется в истории git - как он будет регистрироваться? Как бы выглядел diff?

Я думаю, что проблема в описываемом вами сценарии заключается в том, что UserC не уделял достаточного внимания при слиянии, чтобы заметить ошибку слияния. Хорошее программное обеспечение не исключает необходимости наличия компетентных разработчиков.