Конвейер со сценариями Jenkins или декларативный конвейер

Я пытаюсь преобразовать базовый рабочий процесс моего старого проекта в конвейер на основе Jenkins. Просматривая документы, я обнаружил, что есть два разных синтаксиса: scriptedи declarative. Например, declarativeнедавний выпуск веб- синтаксиса Jenkins (конец 2016 г.). Несмотря на то, что есть новый выпуск синтаксиса, Jenkins по-прежнему поддерживает синтаксис со сценариями.

Я не уверен, в какой ситуации каждый из этих двух типов лучше всего подходит. Так будет declarativeли будущее трубопровода Дженкинса?

Любой, кто может поделиться мыслями об этих двух типах синтаксиса.

При первом создании Jenkins Pipeline в качестве основы был выбран Groovy. Jenkins уже давно поставляет со встроенным движком Groovy, чтобы предоставить расширенные возможности создания сценариев как для администраторов, так и для пользователей. Вдобавок разработчики Jenkins Pipeline обнаружили, что Groovy является прочной основой для построения того, что теперь называется DSL «Scripted Pipeline».

Поскольку это полнофункциональная среда программирования, Scripted Pipeline предлагает пользователям Jenkins огромную гибкость и расширяемость. Кривая обучения Groovy обычно не желательна для всех членов данной команды, поэтому был создан Declarative Pipeline, предлагающий более простой и упорядоченный синтаксис для разработки Jenkins Pipeline.

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

Однако они отличаются синтаксисом и гибкостью. Декларативная ограничивает то, что доступно пользователю, с более строгой и заранее определенной структурой, что делает его идеальным выбором для более простых конвейеров непрерывной доставки. Scripted предоставляет очень мало ограничений, поскольку единственные ограничения по структуре и синтаксису, как правило, определяются самим Groovy, а не какими-либо специфичными для конвейера системами, что делает его идеальным выбором для опытных пользователей и тех, у кого более сложные требования. Как следует из названия, Declarative Pipeline поощряет модель декларативного программирования. В то время как сценарии конвейеров следуют более императивной модели программирования.

Скопировано с https://jenkins.io/doc/book/pipeline/syntax/#compare

Еще одна вещь, которую следует учитывать, это то, что декларативные конвейеры имеют шаг script () . Это может запустить любой конвейер со сценарием. Поэтому я рекомендую использовать декларативные конвейеры и, при необходимости, использовать script()конвейеры со сценариями. Таким образом, вы получаете лучшее из обоих миров.

Недавно я перешел на декларативный режим со сценария с агентом kubernetes. Вплоть до июля 18 года декларативные конвейеры не имели полной возможности указывать модули кубернетов. Однако с добавлением этого yamlFileшага вы теперь можете читать свой шаблон модуля из файла yaml в вашем репо.

Затем это позволяет вам использовать, например, отличный плагин kubernetes vscode для проверки вашего шаблона модуля, затем прочитать его в свой Jenkinsfile и использовать контейнеры по шагам, как вам будет угодно.

pipeline {
  agent {
    kubernetes {
      label 'jenkins-pod'
      yamlFile 'jenkinsPodTemplate.yml'
    }
  }
  stages {
    stage('Checkout code and parse Jenkinsfile.json') {
      steps {
        container('jnlp'){
          script{
            inputFile = readFile('Jenkinsfile.json')
            config = new groovy.json.JsonSlurperClassic().parseText(inputFile)
            containerTag = env.BRANCH_NAME + '-' + env.GIT_COMMIT.substring(0, 7)
            println "pipeline config ==> ${config}"
          } // script
        } // container('jnlp')
      } // steps
    } // stage

Как упоминалось выше, вы можете добавлять блоки скриптов. Пример шаблона модуля с настраиваемым jnlp и докером.

apiVersion: v1
kind: Pod
metadata:
  name: jenkins-pod
spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-slave:3.23-1
    imagePullPolicy: IfNotPresent
    tty: true
  - name: rsync
    image: mrsixw/concourse-rsync-resource
    imagePullPolicy: IfNotPresent
    tty: true
    volumeMounts:
      - name: nfs
        mountPath: /dags
  - name: docker
    image: docker:17.03
    imagePullPolicy: IfNotPresent
    command:
    - cat
    tty: true
    volumeMounts:
      - name: docker
        mountPath: /var/run/docker.sock
  volumes:
  - name: docker
    hostPath:
      path: /var/run/docker.sock
  - name: nfs
    nfs:
      server: 10.154.0.3
      path: /airflow/dags

декларативный - более перспективный вариант, который люди рекомендуют. это единственное, что может поддерживать Visual Pipeline Editor. он поддерживает проверку. и в конечном итоге он имеет большую часть возможностей сценария, поскольку вы можете вернуться к сценарию в большинстве контекстов. иногда кто-то придумывает вариант использования, в котором они не могут делать то, что хотят, с декларативными функциями, но обычно это люди, которые какое-то время использовали сценарии, и эти пробелы в функциях, вероятно, со временем исчезнут.

больше контекста: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

Документация Jenkins правильно объясняет и сравнивает оба типа.

Цитата: «Scripted Pipeline предлагает огромную гибкость и расширяемость для пользователей Jenkins. Кривая обучения Groovy обычно не желательна для всех членов данной команды, поэтому Declarative Pipeline был создан, чтобы предлагать более простой и упорядоченный синтаксис для создание Jenkins Pipeline.

По сути, обе эти подсистемы представляют собой одну и ту же подсистему трубопроводов ".

Подробнее читайте здесь: https://jenkins.io/doc/book/pipeline/syntax/#compare

1. Декларативный конвейер определяется в блоке с меткой «конвейер», тогда как конвейер со сценарием определяется в «узле».
2. Синтаксис - в декларативном конвейере есть «Этапы», «Шаги»
3. Если сборка не удалась, декларативный дает вам возможность снова перезапустить сборку с этого этапа, что неверно в сценарии.
4. Если в сценарии есть какие-либо проблемы, декларативный уведомит вас, как только вы создадите задание, но в случае сценария он пройдет этап, который называется «Хорошо», и выдаст ошибку на этапе, который является «Не в порядке».

Вы также можете сослаться на это. Очень хорошее чтение -> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/ 2194470 / szymon-stepniak? Tab = profile

У меня тоже есть этот вопрос, который привел меня сюда. Декларативный конвейер, безусловно, кажется предпочтительным методом, и я лично считаю его более читаемым, но я пытаюсь преобразовать задание Freestyle среднего уровня сложности в декларативное, и я нашел по крайней мере один плагин, плагин Build Blocker, который я не удается запустить даже в блоке сценария на шаге (я безуспешно пытался поместить соответствующую команду «blockOn» везде, и обычно выдается ошибка «Нет такого метода DSL 'blockOn' среди шагов») .) Итак, я думаю, что поддержка плагинов - это отдельная проблема, даже с блоком сценария (кто-нибудь, пожалуйста, поправьте меня, если я ошибаюсь). Мне также пришлось несколько раз использовать блок сценария, чтобы получить то, что я считаю простым поведением. такие как установка отображаемого имени сборки.

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

Декларативного Pipeline далеко превосходит Scripted трубопровода . Декларативный конвейер может выполнять все, что может выполнять конвейер сценариев, с помощью шага сценария и имеет множество дополнительных функций.

Кроме того, Declarative Pipeline поддерживает различные технологии, такие как Docker или Kubernetes (см. Здесь ).

Декларативный конвейер также является более перспективным. Он все еще находится в разработке, и новые функции, такие как недавно представленная функция Matrix , были добавлены совсем недавно, в конце 2019 года.

tl; dr - Declarative Pipeline может делать все, что может Scripted Pipeline, и даже больше.