TL; DR
Как избежать повторного создания артефактов на главном объекте при объединении объекта без создания нескольких конвейеров для проекта? Где я могу получить информацию о том, какая ветвь была объединена?
Подробнее
Я запускаю Jenkins для создания множества проектов, хранящихся в двух разных V CSs (Gitlab, Bitbucket). Автоматическое обнаружение как для V CSs работает, так и для создания многоотраслевых конвейеров для каждого проекта / ветви / PR, содержащего Jenkinsfile ( Плагин исходного кода ветки Gitlab , Плагин исходного кода ветки Bitbucket ).
Артефакты сборки создаются и сохраняются при каждой сборке (например, docker изображения помещаются в реестр).
По мере того, как я следую за рабочим процессом ветви функций, эти функции в конечном итоге объединяются в master, master будет затем развертывать с нерегулярными интервалами.
При выполнении слияния уже создан и сохранен артефакт для этого кода (см. приложение: 1). Он был создан для ветви функций, из которой был создан код (например, контейнер mysuperapp: feat-add-better-things-3). Я хотел бы взять этот артефакт и рекламировать его как новый главный артефакт (например, mysuperapp: master), избегая перестроения (и тестирования всего модуля + интеграции).
Но объединение ветви функции просто запускает новый конвейер сборки на master-узле без какой-либо информации о слитой ветви (см. приложение: 2). Это правильное поведение в отношении master (новые коммиты, где были выдвинуты), но мешает мне реагировать на объединенную ветвь (например, вышеупомянутое продвижение или даже удаление неиспользованных артефактов). Есть ли способ получить информацию о том, какая ветвь была объединена?
Мне известно, что я могу создать новый конвейер прослушивания PR-обращений с моего V CSs, запустив конвейер для продвижения и полностью игнорировать. Но это перемещает видимость этого процесса в другой конвейер и требует дополнительных конвейеров для проектов, например, уменьшает преимущество автоматического обнаружения до 50% (приходится создавать эти конвейеры слияния для каждого проекта).
Как я могу сохранить преимущества автоматического обнаружения и видимости выполненных шагов, одновременно выполняя что-либо при слиянии?
Идеи: помечать артефакты по-разному, но как (необходимо правильно очищать)? Параметризация конвейеров и настройка единого конвейера слияния, который повторно запускает конвейер 'pu sh on master' с параметрами объединенной ветки. Но можно ли это сделать, не настраивая веб-крючки для каждого проекта? Спросите V CSs через REST о том, какая ветвь принадлежит коммиту?
Привет и спасибо всем за помощь! Это может быть сложным, но было бы здорово заставить это работать. Это последний барьер для меня, чтобы разрешить непрерывную доставку для многих проектов!
Приложение:
1: Я также осознаю, что для получения последовательных сборок я должен применять --ff-only слияния. Этот вопрос не о ловушках git, а о пути к go с Дженкинсом.
2: Git предоставляет мне родительские коммиты, я могу легко выяснить, какие commit был объединен. Но, особенно при использовании «Удалить ветку после слияния», я оставляю без ветку ref в git. Помечая мои docker изображения коммитами вместо веток, я вынужден возвращать последнюю фиксацию в каждой сборке, чтобы удалить старую устаревшую сборку.