Job DSL-plug-in versus pijplijnplug-in

Ik heb uitgebreide ervaring met beide. Een beknopt antwoord is dat Job DSL al veel langer bestaat en de open source-oplossing van Netflix was voor het “coderen” van Jenkins. Het stelde je in staat logica en variabelen te introduceren bij het scripten van je Jenkins-jobs en normaal gesproken zou je deze jobs gebruiken om een ​​soort “pijplijn” te vormen voor een bepaald project. Deze plug-in kreeg behoorlijk wat tractie als een gebruikelijke manier om jobtemplates en scripting mogelijk te maken.

Jenkins Pipeline (2.0) is een nieuwe incarnatie van een Jenkins-taak die volledig is gebaseerd op een DSL en probeert de noodzaak te elimineren om meerdere taken samen te voegen om een ​​enkele pijplijn te vullen, wat verreweg het meest gebruikte gebruik van Job DSL was. . Oorspronkelijk bood Pipeline DSL niet veel van de functies die Job DSL bood, en zoals hierboven vermeld, zou Job DSL u in staat stellen om Pipeline-taken te creëren, ze zouden samen kunnen worden gebruikt om een ​​pijplijn te definiëren.

Tegenwoordig IMO is er weinig reden om Job DSL te gebruiken, omdat Pipeline het door Jenkins ondersteunde mechanisme is voor het scripten van Jenkins-pijplijnen en het heeft veel van de functionaliteit van Job DSL bereikt of overtroffen. Nieuwe plug-ins worden native ontwikkeld voor Pipeline en degenen die dat niet doen, worden door Jenkins-ontwikkelaars aangemoedigd om met Pipeline te integreren. En Pipeline heeft verschillende voordelen:

  • Het is niet nodig om jobs te “seeden” met Pipeline zoals bij Job
    DSL aangezien de pijpleiding de taak zelfis. Met Job DSL is het:
    gewoon een script dat andere jobs creëert.
  • Met Pipeline beschikt u over functies zoals een geparametriseerde handmatige invoerstap, waarmee u logische midstream binnen de pijplijn kunt specificeren
  • De logica die kan zijn
    opgenomen in een Job DSL is beperkt tot het creëren van de jobs
    zich; terwijl je met Pipeline logica rechtstreeks kunt opnemen
    binnen de baan.
  • Job DSL is gewoon veel moeilijker om een ​​basisleveringspijplijn te creëren met bijvoorbeeld de Bouw pijplijn plug-in; als u Pipeline gebruikt, wordt uw bestand kleiner en de syntaxis korter. En als u Job DSL gebruikt om Pipeline-taken te maken, heb ik daar geen grote waarde meer voor gezien, gezien de sjabloonfuncties die kant-en-klaar beschikbaar zijn met Jenkins Pipeline.

Ten slotte is Jenkins Pipeline op dit moment verreweg het meest voorkomende kenmerk van Jenkins. Bekijk de Jenkins World 2016 agendaen je ziet ongeveer. 50% van de sessies hebben betrekking op pijplijn. Geen voor Job DSL.


Antwoord 1, autoriteit 100%

Mijn gevoel is dat de ideale benadering is om beide te gebruiken. Pipeline is de nieuwe native Jenkins-functie om taken als code te hebben. Als je Jenkins echter helemaal opnieuw opbouwt, moeten die banen nog steeds worden gecreëerd. Dit betekent dat Jenkins niet 100% echt kan worden gescript en gebouwd op basis van code.

Wat u kunt doen, is JOB DSL gebruiken om de skeletstructuur van alle taken te bouwen en vervolgens de pijplijn gebruiken voor de implementatie van de taken. Hiermee kun je Jenkins 100% scripten, minus de initiële seed-taak die moet worden gemaakt.

Misschien zullen we uiteindelijk de pijplijn kunnen gebruiken om Jenkins volledig te besturen (beveiliging, configuratie en zelfs plug-ins). Maar tot die tijd denk ik dat het een goede benadering is om DSL en Pipeline te gebruiken.


Antwoord 2, autoriteit 8%

Mijn voorlopige antwoord op basis van zeer beperkte ervaring:

  • Elk gebruikt een andere Groovy DSL.
  • Job DSL geeft je een manier om andere jobs te creëren volgens een Groovy script. Dus als je een set van X-gerelateerde jobs wilt (bijv. een pijplijn), dan maak je één Job DSL-job, schrijf je het script, voer je die job uit, en dan heb je die X-jobs, plus de job om die jobs te creëren. . Op dat moment is alleen de taak die u rechtstreeks hebt gemaakt, uitgevoerd, de taken die door die taak zijn gemaakt niet. OOTB, deze taken zijn nietverborgen zoals Maven-modules in een Maven-taak met meerdere modules zijn verborgen, maar ik begrijp dat er op zijn minst een manier is om een ​​weergave te creëren en de taken daar te plakken.
  • Pipeline DSL blijft gewoon voor onbepaalde tijd hangen in de 2 zeer verschillende omgevingen waar ik het heb geprobeerd. :'( Dit is een bekende showstopper-bug, zoals ik begrijp – zoek en je zult enkele openstaande bug-tickets vinden. Hoe dan ook, het uitvoeren van de Pipeline-taak die je maakt, voert daadwerkelijk de pijplijn uit, genereert niet een heleboel taken zoals de Job DSL Dus triggers om de pijplijntaak uit te voeren zijn triggers om de pijplijn uit te voeren, niet alleen om de taken die het definieert bij te werken.
  • Pipeline lijkt op grotere schaal te worden gebruikt, afgaande op de downloadaantallen. Natuurlijk is Pipeline een standaardfunctie van Jenkins 2.0, wat de recente piek in downloads zou kunnen verklaren. De beheerders van Jenkins willen zeker dat je het gebruikt.

Dus om samen te vatten: de DSL van Job DSL is voor het creëren van banen die een pijplijn vormen, de DSL van Pipeline Plugin definieert de pijplijn zelf.

En om uw vraag(en) te beantwoorden: Pipeline zou in de toekomst breder ondersteund moeten worden, lijkt mij eenvoudiger (de job is een job, geen metajob) en lijkt meer functies te hebben (inclusief workflow). Ik zou het gebruiken tenzij je de bovengenoemde showstopper-bug van doom raakt en geen fix / workaround kunt vinden.


Antwoord 3, autoriteit 8%

Er is één belangrijk onderscheid dat hier tot nu toe niet is genoemd: testen. Met de job-dsl is er een manier om de DSL-code te testen voordat deze wordt vastgelegd in SCM: https ://github.com/sheehan/job-dsl-gradle-example– hierdoor kan een lokale testsuite worden uitgevoerd op DSL-code, evenals in Jenkins, voordat de code wordt uitgevoerd. Voor zover ik weet, is er geen equivalent in de native Pipeline-aanpak.

Other episodes