Как бороться с раскрученными конфликтующими ветками на Дженкинсе

Question

Идея заключается в следующем:

1. все разработчики работают над своими ветками и отправляют их на github
2. jenkins запускает сборки (запускаемые "push on github") в тесте заданий для запуска модульных тестов в этих ветвях функций
3. После прохождения теста менеджер отправляется на github для проверки кода.
4. Если проверка кода в порядке, то эта сборка продвигается (плагин продвижения сборки) вручную в "Pass QA, Ready for prod", в разделе "Actions" мы устанавливаем "триггеры / вызовы сборок для других проектов", чтобы инициировать отдельный тест задания -prod только для слияния этой ветви функций с мастером на удаленном репо.

Тест работы продвигает конфигурацию сборки:

Конфигурация SCM test test-prod:

Итак, 2 вопроса здесь:

1. на шаге 4 мы имеем ситуации, например, две конфликтующие ветви функций, обе из которых прошли проверку кода, первая продвинутая ветвь будет в порядке, но вторая будет иметь конфликты и сбои, есть ли способ обнаружить конфликт раньше? Я знаю, что "объединить перед сборкой" можно избежать конфликта, но это требует, чтобы прежняя ветвь уже была объединена с удаленным мастером

2. В бесконфликтных случаях, когда второе задание запускается продвижением вручную, всегда возникает дополнительная сборка, вызванная: "Устаревший код запустил это задание. Информация о причине недоступна", я понятия не имею, как это происходит.

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

Answer 1

Отказ от ответственности: я ничего не знаю о мерзавце.

В соответствии с этим, наилучшей практикой является использование rebase, Поскольку я не знаком с Git, я не могу сказать вам, как настроить rebase на Дженкинс.

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