Как разделить трубопровод декларативного по многим проектам

у меня есть много проектов в различных хранилищах, которые разделяют те же основные CI-технологический процесс, который я могу легко выразить как трубопровод декларативной:Как разделить трубопровод декларативного по многим проектам

pipeline { 
    agent any 

    options { 
    buildDiscarder(logRotator(numToKeepStr: '20')) 
    } 

    stages { 
    stage('CI') { 
     steps { 
     echo 'Do CI' 
     } 
    } 

    stage('QA') { 
     steps { 
     echo 'Do QA' 
     } 
    } 
    } 

    post { 
    always { 
     junit allowEmptyResults: true, testResults: '**/target/surefire-reports/TEST-*.xml' 
     // etc... 
    } 

    failure { 
     echo 'Failure mail' 
     // etc 
    } 
    } 
}

Я хотел бы использовать тот же декларативный трубопровод во всех моих проектах и иметь возможность изменять определение Pipeline только в одном месте и автоматически менять изменения во всех проектах.

По сути то, что я бы делать в проекте; s Jenkinsfile это:

loadPipelineFromScm 'repository', 'pipeline.groovy'

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

Есть ли способ поделиться Декларативный Трубопровод по многим хранилищам?

источник

2017-02-21 pmr

Вы уверены, что декларативная трубопровод не может работать в общей библиотеке? Документ [Декларативный трубопровод: уведомления и общие библиотеки] (https://jenkins.io/blog/2017/02/15/declarative-notifications/), похоже, делает именно это. Не могли бы вы сделать что-то подобное? – herm

Я занимаюсь этим же вопросом для своей собственной работы. Лучшее решение, которое я мог придумать было включать общий Jenkinsfile в каждом проекте/репо в моей организации:

node 
{ 
    checkout([$class: 'GitSCM', branches: [[name: env.DELIVERY_PIPELINE_BRANCH]], userRemoteConfigs: [[credentialsId: env.DELIVERY_PIPELINE_CREDENTIALS, url: env.DELIVERY_PIPELINE_URL]]]) 
    stash includes: '*.groovy', name: 'assets', useDefaultExcludes: false 
    load './Jenkinsfile.groovy' 
}

я использовал переменные окружения в случае вещей необходимо изменить, вероятно, может быть еще более динамичным, чем мой пример current (все равно все равно в разработке).

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

И наконец, он загружает Декларативный трубопровод. Не смешивается с представлениями, в основном все ведет себя нормально.

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

источник

2017-03-26 04:43:06 noober01

В то время как представления остаются нетронутыми, используя предложение от noober01, декларативный конвейер не будет функционировать должным образом. Например. когда клаузулы будут проигнорированы, поскольку ожидается, что элемент конвейера будет верхним, что означает, что он анализируется как сценарий сценария.

Смотрите следующий вопрос отвергнут командой за Дженкинс: loading external declarative pipelines issue

источник

2017-08-10 09:50:57

Как разделить трубопровод декларативного по многим проектам

ответ

Смежные вопросы