Emploi DSL Plugin Vs Pipeline Plugin

Question

Quelle est la principale différence entre l'Emploi DSL Plugin et Pipeline Plugin

1. les deux fournissent la voie aux programmes de création d'emplois
2. qui est le meilleur à utiliser comme aller de l'avant et pourquoi?
3. si les deux ont des fonctionnalités similaires, ont-ils différents cas d'utilisation?
4. Depuis Jenkins 2.0 est en se concentrant sur les Pipelines en tant que code, est-ce à dire que l'emploi dsl de ne pas avoir un avenir ou d'un Pipeline Plugin est la prochaine étape dans le Travail DSL Plugin?

Answer 1

J'ai une grande expérience avec les deux. Une forme concise, la réponse est que l'Emploi DSL existe depuis bien plus longtemps et a été Netflix de la solution open source de "codage" Jenkins. Il vous a permis d'introduire la logique et des variables dans les scripts de votre Jenkins emplois et, généralement, on pourrait utiliser ces emplois pour former une sorte de "pipeline" pour un projet particulier. Ce plugin a reçu un peu de traction comme un bon moyen d'activer le travail de création de modèles et de scripts.

Jenkins Pipeline (2.0) est une nouvelle incarnation du Jenkins travail qui est entièrement basé sur un DSL et les tentatives pour éliminer le besoin de regrouper plusieurs postes à combler, un seul pipeline qui a été de loin la plus courante de la Tâche DSL. À l'origine, avec Pipeline DSL de ne pas offrir de nombreuses fonctions de l'Emploi DSL a fait, et comme mentionné ci-dessus d'Emploi DSL vous permettrait de créer des travaux de Canalisation, ils pourraient être utilisés ensemble pour définir un pipeline.

Aujourd'hui, de l'OMI, il n'y a guère de raison d'utiliser de l'Emploi DSL parce que le Pipeline est le Jenkins-mécanisme de prise en charge pour l'écriture de scripts Jenkins pipelines et il a atteint ou dépassé la plupart des fonctionnalités de Travail DSL. De nouveaux plugins sont conçus nativement pour le Pipeline, et ceux qui ne sont pas encouragées par Jenkins aux développeurs d'intégrer du Pipeline. Et le Pipeline a plusieurs avantages:

• Il n'est pas nécessaire à la "graine" emplois à l'aide de Pipeline, tel qu'il est, avec l'Emploi DSL depuis le Pipeline est le travail lui-même. Emploi DSL, c'est juste un script qui crée d'autres emplois.
• Avec Pipeline, vous disposez des fonctionnalités telles que un paramétrée de la saisie manuelle de l'étape, vous permettant de spécifier la logique de traitement dans le pipeline
• La logique qui peut être inclus dans un Emploi DSL est limitée à la création des emplois eux-mêmes; tandis qu'avec Pipeline, vous pouvez inclure une logique directement à l'intérieur de l'emploi.
• Emploi DSL est tout simplement beaucoup plus difficile de créer une base de prestation de canalisation à l'aide, par exemple, le Build Pipeline Plugin; à l'aide de Pipeline votre fichier sera plus petit et syntaxe plus courte. Et si vous êtes en utilisant de l'Emploi DSL pour créer des travaux de Canalisation, je n'ai pas vu une grande valeur pour de plus compte tenu de la création de modèles à disposition des fonctionnalités out-of-the-box et Jenkins Pipeline.

Enfin, Jenkins Pipeline est de loin la plus répandue fonction de Jenkins droit maintenant. Découvrez le Jenkins Monde 2016 ordre du jour et vous verrez env. 50% des sessions implique pipeline. Aucun pour l'Emploi DSL.

Answer 2

Mon sentiment est l'approche idéale consiste à utiliser les deux. Pipeline est le natif de Jenkins fonctionnalité d'emplois en tant que code. Toutefois, si le bâtiment Jenkins à partir de zéro, ces travaux doivent encore être créés. Cela signifie Jenkins ne peut pas être 100% vraiment écrit et construit à partir du code.

Ce que vous pouvez faire est d'utiliser de l'EMPLOI DSL pour construire le squelette de la structure de toutes les tâches, puis utiliser le pipeline pour la mise en œuvre des emplois. Cela vous permettra de 100% script Jenkins, moins la graine initiale d'emplois à créer.

Peut-être que, finalement, nous serons en mesure d'utiliser le pipeline de contrôler pleinement Jenkins (sécurité, la configuration et même des plugins). Mais jusqu'alors, je pense que c'est une bonne approche pour utiliser l'adsl et le Pipeline.

Answer 3

Ma réponse préliminaire basée sur une expérience très limitée:

• Chacun utilise un autre Groovy DSL.
• Emploi DSL vous donne un moyen de créer d'autres emplois, selon un script Groovy. Donc, si vous voulez un ensemble de X emplois liés (par exemple, un pipeline de), vous allez créer un Emploi DSL emploi, écrire le script, exécutez ce travail, et puis vous aurez ces X emplois, ainsi que celle de créer ces emplois. À ce stade, seul le travail que vous avez créé directement a été exécuté, celles créées par ce travail n'ont pas. OOTB, ces emplois se sont pas cachées de la façon Maven modules dans un environnement multi-module Maven travail sont cachés, mais je comprends qu'il y ait au moins un moyen de créer une vue et le bâton de l'emploi.
• Pipeline DSL se bloque indéfiniment dans les 2 environnements très différents où j'ai essayé. :'( C'est un obstacle de taille de bug, si je comprends bien--de recherche et vous trouverez quelques bug ouvert billets sur ce. Anywho, l'exécution du Pipeline de travail que vous créez en fait exécute le pipeline, ne génère un tas d'emplois tels que la DSL. Donc déclencheurs pour exécuter le pipeline d'emploi sont des déclencheurs pour exécuter le pipeline, et non pas simplement de mettre à jour les emplois qu'il définit.
• Pipeline semble être plus largement utilisé, à en juger par le nombres de téléchargement. Bien sûr, le Pipeline est une fonction par défaut de Jenkins 2.0, ce qui pourrait expliquer l'augmentation récente dans les téléchargements. Les responsables de Jenkins sûr de vouloir l'utiliser.

Donc pour récapituler: Emploi DSL du DSL est pour la création d'emplois, qui forme un pipeline, Gazoduc du Plugin DSL définit le pipeline lui-même.

Et pour répondre à ta question(s): Pipeline devrait être plus largement pris en charge dans l'avenir, l'air plus simple pour moi (le travail est un travail, pas un metajob), et semble avoir plus de fonctionnalités (y compris les flux de travail). Je voudrais l'utiliser à moins que vous frappez la susmentionnés clou du spectacle bug de doom et ne peut pas trouver une solution / solution de contournement.

Answer 4

Il y a une distinction importante qui n'a pas été mentionné jusqu'ici: les tests. Avec le travail-dsl il y a un moyen de tester le DSL code avant de s'engager à la GCA: https://github.com/sheehan/job-dsl-gradle-example - cela permet une local de la suite de tests à exécuter sur DSL code, ainsi que dans Jenkins, avant l'exécution du code. Autant que je sache, il n'y a pas d'équivalent dans le natif de Pipeline approche.