Многоотраслевой конвейер Jenkins с файлом Jenkins из другого репозитория

Короткий ответ: вы не можете сделать это с multibranch pipeline. Многоотраслевые конвейеры предназначены только (по крайней мере, на данный момент) для выполнения определенного конвейера в стиле Pipeline script from SCM с фиксированным Jenkinsfile в корне проекта.

Однако вы можете использовать созданный плагин Multi-Branch Project для многоотраслевых фристайл-проектов. Во-первых, вам нужно определить свой multibranch freestyle configuration так же, как если бы вы использовали multibranch pipeline configuration. Выберите этот новый элемент, как показано ниже:

Этот тип конфигурации будет вести себя точно так же, как тип multibranch pipeline, т.е. он создаст вам папку с именем вашей конфигурации и подпроектом для каждой автоматически обнаруженной ветки.

Тогда реализация должна быть простой:

1. Укажите свой SCM репозиторий в многоотраслевой конфигурации
2. Вызовите другую сборку как часть вашей сборки / пост-сборки, как и в стандартном проекте фристайла, за исключением того, что вам нужно вызвать параметризованное задание (назовем его build-job) и передать ему информацию о вашем репозитории, то есть URL-адрес Git и текущую ветку (для этой цели можно использовать предварительно определенные переменные $GIT_URL и $GIT_BRANCH)
3. В вашем build-job просто определите либо встроенный конвейер, либо сценарий конвейера, извлеченный из SCM, а внутри этого сценария выполните проверку SCM и продолжайте шаги, которые вам нужно построить. Пример содержимого build-job конвейера:

.

node() {
  stage 'Checkout'
  checkout scm: [$class: 'GitSCM', branches: [[name: '*/${GIT_BRANCH}']], userRemoteConfigs: [[url: '${GIT_URL}']]]

  stage 'Build'
  // Build steps...
}

Конечно, если к вашим различным мультиотраслевым проектам нужно относиться немного по-другому, вы также можете использовать промежуточные проекты (скажем, build-project-A, build-project-B, ...), которые, в свою очередь, будут вызывать общий build-job конвейер)

Одним из основных недостатков этого решения является то, что у вас будет только одно задание, отвечающее за все ваши сборки, что затрудняет отладку. В случае успеха / ошибки ваши многоотраслевые проекты по-прежнему будут синими / красными, но вам придется вернуться к названию build-job, чтобы найти реальную проблему вашей сборки.

У меня версия 2.121, и вы можете сделать это двумя способами:

Способ 1

В конфигурации многоотраслевого конвейера> Конфигурация сборки> Режим> Выберите «Пользовательский сценарий» и введите «Файл маркера» под именем файла, который вы будете использовать для определения ветвей, для которых вы хотите создавать сборки.

Затем под этим в Pipeline> Definition выберите «Pipeline Script from SCM» и введите информацию «SCM», чтобы узнать, как найти «Jenkinsfile», содержащий скрипт, который вы хотите запустить. Он может находиться в том же репозитории, в котором вы находите ветки для создания заданий (если вы вводите ту же информацию репозитория GitHub), но я не могу найти способ указать, что вы просто используете ту же ветку для файла.

Способ 2

То же, что и выше, в конфигурации многоотраслевого конвейера> Конфигурация сборки> Режим> Выберите «Пользовательский сценарий» и введите «Файл маркера» под именем файла, который вы будете использовать для идентификации ветвей, для которых вы хотите создавать сборки.

Затем под ним в Pipeline> Definition выберите «Pipeline Script» и добавьте немного Groovy в текстовое поле, чтобы загрузить все, что вы хотите, или запустить какой-нибудь сценарий, который уже был загружен в рабочую область.

Вы можете использовать этот плагин https://github.com/jenkinsci/pipeline-multibranch-defaults-plugin/blob/master/README.md Где нам нужно настроить jenkinsfile на jenkins вместо того, чтобы иметь его в каждой ветке вашего репо.

Лучший способ, который я нашел, - это использовать плагин Remote Jenkinsfile Provider. https://plugins.jenkins.io/remote-file/

Это добавит опцию плагина Remote Jenkinsfile Provider в разделе Build Configuration ›Mode, после чего вы сможете указать на другое репо, где находится Jenkinsfile. Я считаю, что это гораздо лучшее решение, чем плагин Pipeline Multibranch Defaults, который позволяет хранить файл Jenkins в самом Jenkins, а не в системе управления версиями.

В моем случае у меня есть сценарий с проектом gitlab, основанным на gradle, у которого есть зависимости от другого preject gitlab на основе gradle (та же панель инструментов, но разные коммиты, разные разработчики).

Я добавил следующие строки в свой Jenkinsfile (тот, который зависит)

stage('Build') { 
            steps {
                git branch: 'dev', credentialsId: 'jenkins-generated-ssh-key', url: '[email protected]:root/coreProject.git'
                sh './gradlew clean'  
            }                 
        }

Примечание: обратите внимание на порядок в предложениях. Если у вас есть сомнения относительно того, как создать jenkins-generated-ssh-key, спросите меня