read - Tubería con guión de Jenkins o tubería declarativa

jenkins read jenkinsfile

Question

Estoy tratando de convertir mi flujo de trabajo base de proyecto de estilo antiguo en una tubería basada en Jenkins. Mientras docs , descubrí que hay dos sintaxis diferentes llamadas con scripted y declarative . Como el lanzamiento de la sintaxis declarative web de Jenkins recientemente (finales de 2016). Aunque hay una nueva versión de sintaxis, Jenkins también admite la sintaxis programada.

Ahora, no estoy seguro de en qué situación cada uno de estos dos tipos sería la mejor opción. scripted sintaxis scripted será obsoleta pronto? Entonces, ¿será declarative el futuro del oleoducto Jenkins?

Cualquiera que pueda compartir algunas ideas sobre estos dos tipos de sintaxis.

Answer 1

Cuando se creó Jenkins Pipeline, Groovy fue seleccionada como la base. Jenkins se ha entregado durante mucho tiempo con un motor Groovy incorporado para proporcionar capacidades avanzadas de secuencias de comandos para administradores y usuarios por igual. Además, los implementadores de Jenkins Pipeline encontraron que Groovy era una base sólida sobre la cual construir lo que ahora se conoce como DSL "Scripted Pipeline".

Como es un entorno de programación con todas las funciones, Scripted Pipeline ofrece una gran cantidad de flexibilidad y extensibilidad a los usuarios de Jenkins. La curva de aprendizaje Groovy no suele ser deseable para todos los miembros de un equipo determinado, por lo que Declarative Pipeline se creó para ofrecer una sintaxis más simple y más obstinada para la creación de Jenkins Pipeline.

Los dos son fundamentalmente el mismo subsistema Pipeline debajo. Ambas son implementaciones duraderas de "Pipeline as code". Ambos pueden usar pasos integrados en Pipeline o proporcionados por complementos. Ambos pueden utilizar bibliotecas compartidas

Sin embargo, donde difieren es en sintaxis y flexibilidad. La declaración limita lo que está disponible para el usuario con una estructura más estricta y predefinida, por lo que es una opción ideal para tuberías de entrega continua más simples. Scripted proporciona muy pocos límites, en la medida en que los únicos límites de estructura y sintaxis tienden a ser definidos por Groovy, en lugar de cualquier sistema específico de Pipeline, por lo que es una opción ideal para usuarios avanzados y aquellos con requisitos más complejos. Como su nombre lo indica, Declarative Pipeline fomenta un modelo de programación declarativa. Mientras que los Scripted Pipelines siguen un modelo de programación más imperativo.

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

Answer 2

La documentación de Jenkins explica y compara correctamente ambos tipos.

Para citar: "Scripted Pipeline ofrece una enorme cantidad de flexibilidad y extensibilidad a los usuarios de Jenkins. La curva de aprendizaje Groovy no suele ser deseable para todos los miembros de un equipo determinado, por lo que Declarative Pipeline se creó para ofrecer una sintaxis más simple y más obstinada para autoría de Jenkins Pipeline.

Los dos son fundamentalmente el mismo subsistema Pipeline debajo ".

Lea más aquí: https://jenkins.io/doc/book/pipeline/syntax/#compare

Answer 3

Otra cosa a considerar es que las canalizaciones declarativas tienen un paso de script () . Esto puede ejecutar cualquier canalización programada. Por lo tanto, mi recomendación sería usar tuberías declarativas y, si es necesario, usar script() para tuberías con secuencias de comandos. Por lo tanto, obtienes lo mejor de ambos mundos.

Answer 4

Realicé el cambio a declarativo recientemente desde el script con el agente kubernetes. Hasta julio de 18, las canalizaciones declarativas no tenían la capacidad total de especificar vainas de kubernetes. Sin embargo, con la adición del paso yamlFile ahora puede leer su plantilla de pod desde un archivo yaml en su repositorio.

Esto le permite usar, por ejemplo, el excelente complemento kubernetes de vscode para validar su plantilla de pod, luego leerla en su Jenkinsfile y usar los contenedores en pasos como desee.

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

Como se mencionó anteriormente, puede agregar bloques de script. Ejemplo de plantilla de pod con jnlp y docker personalizados.

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 5

declarativa parece ser la opción más preparada para el futuro y la que la gente recomienda. es el único que admite el Editor de canalización visual. Es compatible con la validación. y termina teniendo la mayor parte del poder de las secuencias de comandos, ya que puede recurrir a las secuencias de comandos en la mayoría de los contextos. de vez en cuando a alguien se le ocurre un caso de uso en el que no pueden hacer lo que quieren hacer con la declaración, pero generalmente se trata de personas que han estado usando secuencias de comandos durante algún tiempo, y es probable que estas brechas de características se cierren a tiempo.

más contexto: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/