Pipeline scripté ou pipeline déclaratif de Jenkins

Question

Je suis en train de convertir mon style ancien projet de la base de flux de travail à un pipeline basé sur Jenkins. En passant par les docs que j'ai trouvé il y a deux syntaxes différentes nommé scripted et declarative. Comme le web de Jenkins declarative de la syntaxe de presse récemment (fin 2016). Bien qu'il y est une nouvelle syntaxe de presse Jenkins prend toujours en charge de script syntaxe.

Maintenant, je ne suis pas sûr dans lequel la situation de chacun de ces deux types serait un meilleur match. scripted de la syntaxe sera bientôt obsolète? Donc, allons - declarative être l'avenir de l'Jenkins pipeline?

N'importe qui peut partager avec vous quelques réflexions à propos de ces deux syntaxe types.

Answer 1

Lorsque Jenkins Pipeline a été créé pour la première fois Groovy a été choisi comme la fondation. Jenkins a longtemps livré avec un intégré à l'Groovy moteur de fournir des capacités de script pour les administrateurs et les utilisateurs. En outre, les réalisateurs de Jenkins Pipeline trouvé Groovy à être une base solide sur laquelle construire ce qui est maintenant appelé le "Script Pipeline" DSL.

Comme il est un complet, environnement de programmation, Scripts Pipeline offre une énorme quantité de flexibilité et d'extensibilité pour Jenkins utilisateurs. Le Groovy de la courbe d'apprentissage n'est généralement pas souhaitable que tous les membres d'une équipe, de manière Déclarative Pipeline a été créé pour offrir un moyen plus simple et plus opiniâtres de la syntaxe pour la création de Jenkins Pipeline.

Les deux sont fondamentalement le même Pipeline sous-système sous-jacente. Ils sont à la fois durable implémentations de "Pipeline du code." Ils sont tous les deux capables d'utiliser les étapes construit des Pipelines ou fournis par les plugins. Les deux sont en mesure d'utiliser les Bibliothèques Partagées

Là où ils diffèrent, cependant, est dans la syntaxe et de la flexibilité. Déclarative limites de ce qui est disponible à l'utilisateur avec la plus stricte et la structure prédéfinie, un choix idéal pour la simple prestation continue des pipelines. Script fournit très peu de limites, dans la mesure où les seules limites sur la structure et la syntaxe ont tendance à être définis par Groovy lui-même, plutôt que d'un Pipeline de systèmes spécifiques, qui en font un choix idéal pour les utilisateurs et ceux avec des exigences plus complexes. Comme son nom l'indique, Déclarative Pipeline encourage un modèle de programmation déclarative. Alors que Scripté Pipelines de suivre un plus impératif modèle de programmation.

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

Answer 2

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, d'utiliser script() pour les pipelines scriptés. Par conséquent, vous obtenez le meilleur des deux mondes.

Answer 3

J'ai fait le switch déclarative récemment de script avec le kubernetes de l'agent. Jusqu'en juillet '18 déclarative pipelines n'ont pas la possibilité de spécifier des kubernetes gousses. Cependant, avec l'ajout de l' yamlFile étape, vous pouvez désormais lire votre pod modèle à partir d'un fichier yaml dans votre pension.

Cela vous permet ensuite d'utiliser, par exemple, vscode du grand kubernetes plugin pour valider votre pod modèle, puis de le lire dans votre Jenkinsfile et l'utilisation des conteneurs dans les étapes que vous s'il vous plaît.

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 gousse de modèle personnalisé avec jnlp et 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

Answer 4

déclarative semble être le plus de l'avenir de l'option et celui que les gens recommandent. c'est le seul que le Visuel Pipeline Éditeur peut prendre en charge. il prend en charge la validation. et il finit par avoir la plupart de la puissance de scénario puisque vous pouvez revenir à des écrits dans la plupart des contextes. parfois, quelqu'un arrive avec un cas d'utilisation où ils ne peuvent pas vraiment faire ce qu'ils veulent faire avec déclarative, mais c'est généralement des gens qui ont été à l'aide de scripts pour un certain temps, et ceux-ci comportent des lacunes sont susceptibles de fermer dans le temps.

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

Answer 5

Le Jenkins documentation correctement décrit et compare les deux types.

Pour citer: "Scripté Pipeline offre une énorme quantité de flexibilité et d'extensibilité pour Jenkins utilisateurs. Le Groovy de la courbe d'apprentissage n'est généralement pas souhaitable que tous les membres d'une équipe, de manière Déclarative Pipeline a été créé pour offrir un moyen plus simple et plus opiniâtres de la syntaxe pour la création de Jenkins Pipeline.

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

Lire la suite ici:https://jenkins.io/doc/book/pipeline/syntax/#compare