В настоящее время я тестирую конвейерный подход Jenkins 2.0, чтобы убедиться, что он работает в среде сборки, которую я использую.
Сначала о самой окружающей среде. В настоящее время он состоит из нескольких репозиториев SCM. Каждый репозиторий содержит несколько веток для разных этапов разработки, и каждая ветвь строится с несколькими конфигурациями. Не все конфигурации применимы к каждому репозиторию.
В настоящее время каждый репозиторий / ветка настроен как матрица Project для разных конфигураций. Каждый проект представляет результаты своего строительства как артефакт, и эти артефакты используются в последующих проектах.
Различные репозитории зависят друг от друга, поэтому успешная сборка восходящего задания запускает некоторые определенные нисходящие задания. В настоящее время все это работает, но объем работы, необходимой для создания новой ветки или настройки процесса сборки, велик, поскольку многие различные проекты необходимо изменять вручную.
Теперь я хотел попробовать новые конвейеры. Моя идея заключалась в том, чтобы создать проекты конвейеров с несколькими ветвями и поместить Jenkinsfile
в репозиторий, содержащий инструкции для сборки.
Основная проблема - заставить сборки запускать друг друга, потому что в основном сборка в определенной восходящей ветке должна запускать нисходящую ветвь. Однако информация о том, какие ответвления должны быть запущены, не известна вышестоящему проекту. Каждый последующий проект извлекает артефакты из некоторых вышестоящих ветвей, и идеальным решением было бы, если бы последующая сборка была бы запущена в случае, если восходящая сборка, которая является источником для артефакта, завершит свою сборку.
Проблема в том, что только нижележащие проекты действительно знают, какие артефакты им нужны. В большинстве случаев имена веток вряд ли будут совпадать, и это очень затрудняет запуск сборок из восходящего проекта.
В настоящее время это решается с помощью ReverseBuildTrigger
. Но эта штука перестает работать, как только приближается к трубопроводу.
Я действительно не понимаю, как заставить это работать. Есть ли способ получить что-то вроде _3 _ работа внутри скриптов конвейера?
Кроме того, запуск всей нисходящей сборки для всех ветвей в случае изменения одной восходящей ветки не является вариантом. Это создало бы слишком много одинаковых сборок.