Jenkins сценарий трубопровода или декларативного трубопровода

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Оба они оба принципиально являются одной и той же подсистемой Pipeline внизу.

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

Ответ 4

Еще одна вещь, которую следует учитывать, - это декларативные конвейеры с шагом script(). https://jenkins.io/doc/pipeline/steps/pipeline-model-definition/#code-script-code-run-arbitrary-pipeline-script Это может запускать любой скриптовый сценарий. Поэтому моя рекомендация будет заключаться в использовании декларативных конвейеров, и при необходимости используйте script() для сценариев. Поэтому вы получаете лучшее из обоих миров.