Конвейер для использования артефактов из 2 проектов, связанных с одним и тем же именем ветки git

Question

Компания, в которой я работаю, оценивает jenkins 2.71, в частности, конвейер и плагины Blue Ocean. Мы уже протестировали и GoCD, и нам, как и в GoCD, нужен способ для конвейера автоматически извлекать артефакты из 2 других конвейеров (принимая последний успешный результат каждого из них), в нашем случае.

У нас есть эти начальные конвейеры (тесты сборки и запуска), которые отражают 2 проекта:

• фронтенд, ~ 15 минут
• бэкэнд, ~10 минут

Я создал конвейер с именем configure (~ 1 минута), например, с параметром под названием customer-name, который берет файлы бэкэнда и внешнего интерфейса и объединяет их, затем применяет специфические для клиента конфигурации и настройки и создает развертываемые артефакты. Вместо "имени клиента" я также мог бы распараллелить эту работу, чтобы создать все артефакты для каждого клиента одновременно, разделенные в разных каталогах.

Следующим конвейером будет развертывание их на разных тестовых серверах, отдельно для каждого клиента. Это также может быть частью того же конвейера конфигурации, нам еще нужно посмотреть, как все сложить в jenkins...

В идеале мне нужно настроить конвейер так, чтобы он запускался автоматически (или также по требованию) после каждого успешного выполнения интерфейса или бэкэнда и принимал в качестве входных данных последние успешные артефакты из этих 2 конвейеров, а не только последнюю успешную сборку, нам нужна в качестве зависимости git название филиала

Например, у нас есть:

внутренние ветви:

• мастер
• выпуск /2017,2

передние конечности:

• мастер
• выпуск /2017,2

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

В процессе поиска я обнаружил плагин Copy Artifact

Но теперь большой вопрос, как извлечь последние успешные артефакты из этих конвейеров с тем же именем git branch?

Поскольку мы не хотим смешивать, например, внутреннюю сборку "release/2017.2" с внешним интерфейсом "master", она должна быть найдена как последняя успешная сборка, имеющая те же отношения или параметр, или как вы хотите это назвать, в нашем случае ассоциация - это имя ветки git.

Можно ли этого добиться? Если да, то как?

Плагин копирования артефактов, похоже, работает в проекте фристайл. Будет ли это работать в конвейере? Это тоже проблема...

Спасибо

Answer 1

Да, плагин Copy Artifact работает как в вольном, так и в конвейерном проектах; трубопровод использует copyArtifact функция, на которую я ссылался в своем комментарии. Обратите внимание, что если вы перейдете по ссылке Синтаксис конвейера, она будет скрыта: сначала нужно выбрать "step: General Build Step" из раскрывающегося списка, то он даст вам сборщик команд конвейера копирования артефакта.

Я собираюсь предположить, что ваш frontend а также backend проекты создаются как многоотраслевые конвейеры, так как это, вероятно, будет проще поддерживать, чтобы вам не приходилось создавать новые проекты для каждого выпуска. Вы можете ссылаться на эти проекты из других проектов, ссылаясь на <project name>/<branch name> (иногда мне приходилось заменять / с %2f вместо этого я думаю в основном о проектах в стиле фристайл). Затем вы можете настроить свой configure проект как параметризованная сборка (конвейер или фристайл), скажем, со строковым параметром PROJECT_BRANCH_NAME, Затем вставьте следующее в ваши сценарии конвейера проекта frontend / backend, чтобы запустить сборку configure проект

build job: 'configure', parameters: [[$class: 'StringParameterValue', name: 'PROJECT_BRANCH_NAME', value: ${env.BRANCH_NAME}]]

Тогда вы должны просто иметь возможность сделать configure ссылка на проект frontend/%PROJECT_BRANCH_NAME% а также backend/%PROJECT_BRANCH_NAME% (или же ${env.PROJECT_BRANCH_NAME} в сценарии конвейера) при копировании артефактов.

Кроме того, есть ли конкретная причина, почему вы оцениваете именно Jenkins 2.7? 2.7 исполнился год, и с тех пор было выпущено несколько новых релизов LTS. Я бы порекомендовал оставаться в курсе последних событий, если только вы не знаете, что вам нужна конкретная причина 2.7.