Jenkins-Skript-Pipeline oder deklarative Pipeline

Ich versuche, meinen alten Projektbasis-Workflow in eine auf Jenkins basierende Pipeline zu konvertieren. Beim Durchgehen der Dokumente stellte ich fest, dass es zwei verschiedene Syntaxen mit dem Namen scriptedund gibt declarative. Wie die declarativekürzlich veröffentlichte Jenkins-Web- Syntax (Ende 2016). Obwohl es eine neue Syntaxversion gibt, unterstützt Jenkins auch weiterhin die Skriptsyntax.

Jetzt bin ich mir nicht sicher, in welcher Situation jeder dieser beiden Typen am besten zusammenpassen würde. scriptedSyntax wird bald veraltet sein? Wird declarativealso die Zukunft der Jenkins-Pipeline sein?

Jeder, der einige Gedanken zu diesen beiden Syntaxtypen teilen kann.

Bei der ersten Erstellung der Jenkins-Pipeline wurde Groovy als Grundlage ausgewählt. Jenkins wird seit langem mit einer integrierten Groovy-Engine ausgeliefert, um Administratoren und Benutzern erweiterte Skriptfunktionen zu bieten. Darüber hinaus stellten die Implementierer von Jenkins Pipeline fest, dass Groovy eine solide Grundlage für den Aufbau des DSL ist, das jetzt als "Scripted Pipeline" bezeichnet wird.

Da es sich um eine voll funktionsfähige Programmierumgebung handelt, bietet Scripted Pipeline Jenkins-Benutzern eine enorme Flexibilität und Erweiterbarkeit. Die Groovy-Lernkurve ist normalerweise nicht für alle Mitglieder eines bestimmten Teams wünschenswert. Daher wurde die deklarative Pipeline erstellt, um eine einfachere und einfühlsamere Syntax für die Erstellung der Jenkins-Pipeline zu bieten.

Die beiden sind im Grunde das gleiche Pipeline-Subsystem darunter. Sie sind beide dauerhafte Implementierungen von "Pipeline als Code". Beide können in Pipeline integrierte oder von Plugins bereitgestellte Schritte verwenden. Beide können gemeinsam genutzte Bibliotheken verwenden

Wo sie sich jedoch unterscheiden, liegt in der Syntax und Flexibilität. Deklarativ begrenzt das, was dem Benutzer zur Verfügung steht, durch eine strengere und vordefinierte Struktur, was es zu einer idealen Wahl für einfachere Pipelines für die kontinuierliche Lieferung macht. Scripted bietet nur sehr wenige Einschränkungen, da die einzigen Einschränkungen für Struktur und Syntax eher von Groovy selbst als von Pipeline-spezifischen Systemen definiert werden. Dies macht es zu einer idealen Wahl für Power-User und solche mit komplexeren Anforderungen. Wie der Name schon sagt, fördert Declarative Pipeline ein deklaratives Programmiermodell. Während Scripted Pipelines einem zwingenderen Programmiermodell folgen.

Kopiert von https://jenkins.io/doc/book/pipeline/syntax/#compare

Eine andere zu berücksichtigende Sache ist, dass deklarative Pipelines einen script () - Schritt haben . Dies kann jede Skript-Pipeline ausführen. Daher würde ich empfehlen, deklarative Pipelines zu verwenden und bei Bedarf script()für Pipeline-Skripte zu verwenden. So bekommen Sie das Beste aus beiden Welten.

Ich habe kürzlich von einem Skript mit dem Kubernetes-Agenten auf deklarativ umgestellt. Bis zum 18. Juli hatten deklarative Pipelines nicht die volle Fähigkeit, Kubernetes-Pods zu spezifizieren. Mit dem zusätzlichen yamlFileSchritt können Sie jetzt Ihre Pod-Vorlage aus einer Yaml-Datei in Ihrem Repo lesen.

Auf diese Weise können Sie beispielsweise das großartige Kubernetes-Plugin von vscode verwenden, um Ihre Pod-Vorlage zu validieren, sie dann in Ihre Jenkins-Datei einlesen und die Container nach Belieben in Schritten verwenden.

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

Wie oben erwähnt, können Sie Skriptblöcke hinzufügen. Beispiel-Pod-Vorlage mit benutzerdefiniertem JNLP und Docker.

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

deklarativ scheint die zukunftssicherere Option zu sein und die, die die Leute empfehlen. Dies ist die einzige, die der Visual Pipeline Editor unterstützen kann. Es unterstützt die Validierung. und es hat am Ende die meiste Kraft von Skripten, da Sie in den meisten Kontexten auf Skripte zurückgreifen können. Gelegentlich kommt jemand auf einen Anwendungsfall, bei dem er nicht ganz das tun kann, was er mit deklarativ tun möchte. Dies sind jedoch im Allgemeinen Personen, die seit einiger Zeit Skripte verwenden, und diese Funktionslücken schließen sich wahrscheinlich mit der Zeit.

Weitere Informationen: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

In der Jenkins-Dokumentation werden beide Typen richtig erklärt und verglichen.

Um es zu zitieren: "Scripted Pipeline bietet Jenkins-Benutzern eine enorme Flexibilität und Erweiterbarkeit. Die Groovy-Lernkurve ist normalerweise nicht für alle Mitglieder eines bestimmten Teams wünschenswert. Daher wurde Declarative Pipeline erstellt, um eine einfachere und einfühlsamere Syntax für zu bieten Authoring Jenkins Pipeline.

Die beiden sind im Grunde das gleiche Pipeline-Subsystem darunter. "

Lesen Sie hier mehr: https://jenkins.io/doc/book/pipeline/syntax/#compare

1. Die deklarative Pipeline wird in einem Block mit der Bezeichnung "Pipeline" definiert, während die Skript-Pipeline in einem "Knoten" definiert wird.
2. Syntax - Deklarative Pipeline hat 'Stufen', 'Schritte'
3. Wenn der Build fehlgeschlagen ist, können Sie mit deklarativem Build den Build ab dieser Phase erneut starten, was in der Skriptoption nicht der Fall ist
4. Wenn bei der Skripterstellung ein Problem auftritt, werden Sie vom deklarativen Benutzer benachrichtigt, sobald Sie den Job erstellen. Bei Skripten wird jedoch die Phase "Okay" bestanden und ein Fehler auf der Bühne "Nicht OK" ausgegeben.

Sie können dies auch verweisen. Eine sehr gute Lektüre -> 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

Die deklarative Pipeline ist der Scripted Pipeline weit überlegen . Die deklarative Pipeline ist in der Lage , alles , dass die Scripted Pipeline kann ausgeführt werden, indem die Verwendung von Script-Schritt und hat eine Menge zusätzliche Funktionen.

Darüber hinaus unterstützt die deklarative Pipeline verschiedene Technologien wie Docker oder Kubernetes (siehe hier ).

Die deklarative Pipeline ist auch zukunftssicherer. Es befindet sich noch in der Entwicklung und neue Funktionen wie die neu eingeführte Matrix- Funktion wurden erst Ende 2019 hinzugefügt.

tl; dr - Deklarative Pipeline kann alles, was die Skript-Pipeline kann, und noch mehr.