Многоканальный конвейер Jenkins только для подпапки

У меня есть git monorepo с разными приложениями. В настоящее время у меня есть один файл Jenkinsfile в корневой папке, содержащий конвейер для всех приложений. Выполнение полного конвейера для всех приложений занимает очень много времени, если фиксация изменила только одно приложение.

Мы используем подход к ветвлению, подобный GitFlow, поэтому задания Multibranch Pipeline в Jenkins идеально подходят для нашего проекта.

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

Идеальное решение для меня выглядит так:

У меня есть несколько вакансий Multibranch Pipeline в Jenkins. Каждый ищет изменения только в данном каталоге и подкаталогах. Каждый использует собственный Jenkinsfile. Задания вытягивают git каждые X минут, и если есть изменения в соответствующих каталогах в существующих ветках - запускает сборку; при появлении новых веток с изменениями в соответствующих каталогах - запускает сборку.

Что мне мешает от этой реализации

  1. Мне не хватает способа определить фиксацию того, какие папки следует игнорировать во время выполнения сканирования с помощью Multibranch pipeline. «Дополнительное поведение» для многоотраслевого конвейера не имеет опции «Опрос игнорирует фиксации определенных путей», в то время как задания конвейера или фристайла имеют. Но я хочу использовать Multibranch pipeline.

  2. Решение описано здесь не работает для меня, потому что если будет новая ветка с изменениями только для «project1», то всякий раз, когда будет запущен Multibranch pipeline для «project2», он все равно обнаружит эту новую ветку и построит ее. Значит, для каждой новой ветки каждый из моих многоотраслевых конвейеров будет выполняться хотя бы один раз, независимо от того, были ли изменения в соответствующем коде или нет.

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


jenkins jenkins-pipeline monorepo jenkins-blueocean
person mrzodiak    schedule 12.02.2018    source источник
comment
Вы можете попробовать использовать wiki.jenkins.io/display/JENKINS/FSTrigger+Plugin. Этот вариант отлично работал у меня в конвейерных и фристайл-проектах, но не в многоотраслевых, даже несмотря на то, что параметр конфигурации появился в пользовательском интерфейсе конфигурации задания. Если попробуете, скажите, каков был результат, или это просто мое окружение   -  person minas    schedule 12.02.2018
comment
Вы нашли решение ?   -  person cyberjoac    schedule 16.07.2020

Ответы (3)


arrow_upward
9
arrow_downward

Я решил это, создав проект, который строит другие проекты в зависимости от измененных файлов. Например, из корня вашего репо:

/ Jenkinsfile

#!/usr/bin/env groovy

pipeline {
    agent any
    options {
        timestamps()
    }
    triggers {
        bitbucketPush()
    }
    stages {
        stage('Build project A') {
            when {
                changeset "project-a/**"
            }
            steps {
                build 'project-a'
            }
        }
        stage('Build project B') {
            when {
                changeset "project-b/**"
            }
            steps {
                build 'project-b'
            }
        }
    }
}

Тогда у вас будут другие проекты Pipeline с их собственным Jenkinsfile (то есть project-a / Jenkinsfile).

person gzzo    schedule 26.07.2018
comment
Не могли бы вы добавить немного дополнительной информации? Я читал документацию по этапам сборки, но это все еще сбивает с толку, и когда я использовал ваш пример, все, что я получил, это: ОШИБКА: не найден элемент с именем project-a - person oglop; 21.01.2020
comment
У меня нет такого монорепозитория, но, черт возьми, мне нравится этот совет. У меня есть этап, на котором запускается дорогостоящий валидатор для файлов, которые редко меняются, и это идеально подходит для пропуска этого этапа, если ничего не изменилось. - person StormeHawke; 28.02.2020

arrow_upward
7
arrow_downward

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

  1. Установите плагин
  2. В конфигурации многоотраслевого конвейера добавьте Стратегию сборки
  3. Выберите Стратегия создания включенных регионов.
  4. Поместите подпапку в поле, например subfolder/**

Образец изображения конфигурации здесь

Таким образом, изменения все равно будут обнаружены, но они не будут запускать сборку, если она не принадлежит определенному набору файлов или папок.

Это лучший из известных мне подходов. Но я думаю, что лучшим выходом будет случай, когда изменения даже не обнаруживаются.

Изменить: конфигурация плагина Gerrit Code Review

Если вы используете плагин Gerrit Code Review, вы также можете предотвратить обнаружение новых изменений с помощью специального запроса:

Пример конфигурации Gerrit Code Review

person felipecrs    schedule 27.01.2020
comment
спасибо спасибо спасибо спасибо У меня было примерно 5 заданий по переносу более 20 репозиториев в монорепозиторий, и я просто понял, что любое изменение в монорепозитории запускало все 5 заданий ... это то, что мне было нужно. - person Adam Hughes; 21.04.2021

arrow_upward
0
arrow_downward

Я знаю, что этот пост довольно старый, но я решил эту проблему, изменив параметр «включить ветки» для репозиториев SVN (это также можно сделать с помощью свойства «Фильтр по имени (с подстановочными знаками)» для репозиториев git). Вместо того, чтобы указывать только фактическое имя ветки, я также включил подпапку. Поэтому вместо того, чтобы указывать только «ствол», я использовал «ствол / подпапка». Это ограничивает сканирование только этим конкретным каталогом. Обратите внимание, что я еще не полностью протестировал это решение.

person Marty    schedule 23.12.2019