Pipeline scripté Jenkins ou pipeline déclaratif

J'essaie de convertir mon flux de travail de base de projet à l'ancienne en un pipeline basé sur Jenkins. En parcourant la documentation, j'ai trouvé qu'il y avait deux syntaxes différentes nommées scriptedet declarative. Comme la declarativeversion récente de la syntaxe Web Jenkins (fin 2016). Bien qu'il existe une nouvelle version de syntaxe, Jenkins prend également en charge la syntaxe scriptée.

Maintenant, je ne suis pas sûr dans quelle situation chacun de ces deux types serait le meilleur match. scriptedla syntaxe sera bientôt obsolète? Alors, sera declarativel'avenir du pipeline Jenkins?

Quiconque peut partager quelques réflexions sur ces deux types de syntaxe.

Lorsque Jenkins Pipeline a été créé pour la première fois, Groovy a été choisi comme fondation. Jenkins est depuis longtemps livré avec un moteur Groovy intégré pour fournir des capacités de script avancées pour les administrateurs et les utilisateurs. De plus, les réalisateurs de Jenkins Pipeline ont trouvé que Groovy était une base solide sur laquelle construire ce que l'on appelle maintenant le DSL «Scripted Pipeline».

Comme il s'agit d'un environnement de programmation complet, Scripted Pipeline offre une énorme flexibilité et une extensibilité aux utilisateurs de Jenkins. La courbe d'apprentissage Groovy n'est généralement pas souhaitable pour tous les membres d'une équipe donnée, c'est pourquoi le Pipeline déclaratif a été créé pour offrir une syntaxe plus simple et plus avisée pour la création de Jenkins Pipeline.

Les deux sont fondamentalement le même sous-système de pipeline en dessous. Ce sont tous deux des implémentations durables de «Pipeline as code». Ils sont tous deux capables d'utiliser des étapes intégrées à Pipeline ou fournies par des plugins. Les deux peuvent utiliser des bibliothèques partagées

Là où ils diffèrent cependant, c'est dans la syntaxe et la flexibilité. La déclaration limite ce qui est disponible pour l'utilisateur avec une structure plus stricte et prédéfinie, ce qui en fait un choix idéal pour des pipelines de livraison continue plus simples. Scripted fournit très peu de limites, dans la mesure où les seules limites sur la structure et la syntaxe ont tendance à être définies par Groovy lui-même, plutôt que par tout système spécifique à Pipeline, ce qui en fait un choix idéal pour les utilisateurs expérimentés et ceux qui ont des exigences plus complexes. Comme son nom l'indique, Declarative Pipeline encourage un modèle de programmation déclarative. Alors que les pipelines scriptés suivent un modèle de programmation plus impératif.

Copié de https://jenkins.io/doc/book/pipeline/syntax/#compare

Une autre chose à considérer est que les pipelines déclaratifs ont une étape script () . Cela peut exécuter n'importe quel pipeline scripté. Ma recommandation serait donc d'utiliser des pipelines déclaratifs et, si nécessaire, script()des pipelines scriptés. Par conséquent, vous obtenez le meilleur des deux mondes.

J'ai récemment basculé en déclaratif à partir d'un script avec l'agent kubernetes. Jusqu'en juillet 18, les pipelines déclaratifs n'avaient pas la pleine capacité de spécifier des pods kubernetes. Cependant, avec l'ajout de l' yamlFileétape, vous pouvez maintenant lire votre modèle de pod à partir d'un fichier yaml dans votre dépôt.

Cela vous permet ensuite d'utiliser par exemple l'excellent plugin kubernetes de vscode pour valider votre modèle de pod, puis de le lire dans votre fichier Jenkins et d'utiliser les conteneurs par étapes à votre guise.

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

Comme mentionné ci-dessus, vous pouvez ajouter des blocs de script. Exemple de modèle de pod avec jnlp et docker personnalisés.

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

déclarative semble être l'option la plus pérenne et celle que les gens recommandent. c'est le seul que Visual Pipeline Editor puisse prendre en charge. il prend en charge la validation. et il finit par avoir la plupart de la puissance du script puisque vous pouvez revenir au script dans la plupart des contextes. Parfois, quelqu'un propose un cas d'utilisation où il ne peut pas tout à fait faire ce qu'il veut faire avec déclaratif, mais il s'agit généralement de personnes qui utilisent des scripts depuis un certain temps, et ces lacunes de fonctionnalités sont susceptibles de se combler avec le temps.

plus de contexte: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

La documentation Jenkins explique et compare correctement les deux types.

Pour citer: "Scripted Pipeline offre une énorme flexibilité et extensibilité aux utilisateurs de Jenkins. La courbe d'apprentissage Groovy n'est généralement pas souhaitable pour tous les membres d'une équipe donnée, donc Declarative Pipeline a été créé pour offrir une syntaxe plus simple et plus avisée pour création de Jenkins Pipeline.

Les deux sont fondamentalement le même sous-système Pipeline en dessous. "

En savoir plus ici: https://jenkins.io/doc/book/pipeline/syntax/#compare

1. Le pipeline déclaratif est défini dans un bloc intitulé «pipeline» tandis que le pipeline scripté est défini dans un «nœud».
2. Syntaxe - Le pipeline déclaratif a des «étapes», des «étapes»
3. Si la construction échoue, la version déclarative vous donne la possibilité de redémarrer la construction à partir de cette étape, ce qui n'est pas vrai dans l'option script
4. S'il y a un problème dans le script, le déclaratif vous en informera dès que vous construisez le travail mais en cas de script, il passera l'étape qui est `` OK '' et lancera une erreur sur la scène qui est `` Pas ok ''

Vous pouvez également le référer. Une très bonne lecture -> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/ 2194470 / szymon-stepniak? Tab = profil

Le pipeline déclaratif est bien supérieur au pipeline scripté . Le pipeline déclaratif est capable d'exécuter tout ce que le pipeline scripté peut en utilisant l'action de script et dispose de nombreuses fonctionnalités supplémentaires.

De plus, le pipeline déclaratif prend en charge diverses technologies telles que Docker ou Kubernetes (voir ici ).

Le pipeline déclaratif est également plus évolutif. Il est toujours en développement et de nouvelles fonctionnalités telles que la nouvelle fonctionnalité Matrix ont été ajoutées récemment à la fin de 2019.

tl; dr - Le pipeline déclaratif peut faire tout ce que le pipeline scripté peut et même plus.