Дженкинс: запуск многоотраслевого конвейера при восходящем изменении
В настоящее время я тестирую конвейерный подход Jenkins 2.0, чтобы увидеть, работает ли он в среде сборки, которую я использую.
Сначала о самой окружающей среде. В настоящее время он состоит из нескольких хранилищ SCM. Каждый репозиторий содержит несколько веток, для разных этапов разработки, и каждая ветка строится с несколькими конфигурациями. Не все конфигурации применимы к каждому репозиторию.
В настоящее время каждый репозиторий / ветка настроен как матричный проект для различных конфигураций. Каждый проект представляет свои результаты строительства как артефакт, и эти артефакты используются в последующих проектах.
Различные репозитории зависят друг от друга, поэтому успешная сборка вышестоящего задания запускает некоторые конкретные задания вниз по течению. В настоящее время все это работает, но объем работ, необходимых для настройки новой ветви или настройки процесса сборки, очень велик, поскольку многие различные проекты необходимо изменять вручную.
Теперь я хотел попробовать новые трубопроводы. Моя идея состояла в том, чтобы создать многоотраслевые трубопроводные проекты и разместить Jenkinsfile
внутри репозитория, содержащего инструкции по сборке.
Основная проблема состоит в том, чтобы заставить сборки запускать друг друга, потому что, в основном, сборка в конкретной ветке upstream должна запускать ветку downstream. Однако информация о том, какие нисходящие ветви должны быть запущены, неизвестна вышестоящему проекту. Каждый нисходящий проект выбирает артефакты из некоторых веток восходящего потока, и идеальным решением было бы, если бы нисходящая сборка была бы запущена в случае, если вышестоящая сборка, являющаяся источником для артефакта, завершает свою сборку.
Проблема в том, что только нижестоящие проекты действительно знают, какие артефакты им нужны. Имена ветвей в большинстве случаев вряд ли совпадают, что затрудняет запуск сборок из вышестоящего проекта.
В настоящее время это решается с помощью ReverseBuildTrigger
, Но эта штука перестает работать, как только она приближается к трубопроводу.
Я действительно в растерянности, как заставить это работать. Есть ли способ получить что-то вроде ReverseBuildTrigger
работа внутри конвейерных скриптов?
Кроме того, запуск всей нисходящей сборки для всех ветвей в случае изменения одной ветки в восходящем направлении не возможен. Это создаст слишком много равных сборок.
3 ответа
В настоящее время я пытаюсь заставить это работать для нашего развертывания. Самое близкое, что у меня есть, это добавление следующего к нижестоящему Jenkinsfile;
properties([
pipelineTriggers([
triggers: [
[
$class: 'jenkins.triggers.ReverseBuildTrigger',
upstreamProjects: "some_project", threshold: hudson.model.Result.SUCCESS
]
]
]),
])
Это, по крайней мере, заставляет Дженкинса признать, что он должен запускаться, когда 'some_project' get собран, т.е. он появляется на странице "Просмотр конфигурации".
Однако до сих пор сборки some_project по-прежнему не запускают последующий проект, как ожидалось.
При этом, может быть, вам повезет больше. Дайте мне знать, если это работает для вас.
(Кто-то еще задал похожий вопрос многоотраслевого конвейера Jenkins и уточнил проекты в восходящем направлении)
Если вы используете декларативный многоотраслевой конвейер, вы можете использовать:
triggers {
upstream(upstreamProjects: "some_project/some_branch", threshold: hudson.model.Result.SUCCESS)
}
Если вы хотите, чтобы сопоставление ветвей происходило между зависимостями, вы можете использовать:
triggers {
upstream(upstreamProjects: "some_project/" + env.BRANCH_NAME.replaceAll("/", "%2F"), threshold: hudson.model.Result.SUCCESS)
}
Конфигурация конвейерного задания все еще изначально поддерживает триггеры сборки, включая триггер обратной сборки, сборку после сборки других проектов. Вы даже можете указать ветку из многоотраслевого проектаPipeline.
К сожалению, обратный запуск недоступен. Самое близкое к обратному запуску вы можете получить с помощью плагина Promoted Builds. Но это все еще не позволяет вам настраивать каждую ветку.
Дополнительно Snippet Generator уточняет:
Следующие переменные в настоящее время недоступны внутри сценария конвейера:
NODE_LABELS WORKSPACE SCM-специфичные переменные, такие как SVN_REVISION
пс. Возможно, единственным способом было бы подсказывать от восходящего до нисходящего потоков.