Canalización con script de Jenkins o canalización declarativa

Estoy tratando de convertir mi flujo de trabajo de base de proyectos de estilo antiguo en una canalización basada en Jenkins. Mientras revisaba los documentos , descubrí que hay dos sintaxis diferentes llamadas scriptedy declarative. Como el declarativelanzamiento de la sintaxis web de Jenkins recientemente (finales de 2016). Aunque hay una nueva versión de sintaxis, Jenkins también admite la sintaxis con guiones.

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

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

Cuando se creó Jenkins Pipeline, se seleccionó a Groovy como base. Jenkins lleva mucho tiempo con un motor Groovy integrado para proporcionar capacidades avanzadas de scripting tanto para administradores como para usuarios. 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 enorme cantidad de flexibilidad y extensibilidad a los usuarios de Jenkins. La curva de aprendizaje de 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 obstinada para la creación de Jenkins Pipeline.

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

Sin embargo, donde difieren es en sintaxis y flexibilidad. Declarative limita lo que está disponible para el usuario con una estructura más estricta y predefinida, lo que lo convierte en 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 en la estructura y la sintaxis tienden a ser definidos por el propio Groovy, en lugar de cualquier sistema específico de Pipeline, lo que lo convierte en 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 Scripted Pipelines sigue un modelo de programación más imperativo.

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

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

Hice el cambio a declarativo recientemente desde un script con el agente de kubernetes. Hasta julio de 2018, las canalizaciones declarativas no tenían la capacidad total de especificar pods de kubernetes. Sin embargo, con la adición del yamlFilepaso, 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 leerlo en su archivo Jenkins y usar los contenedores en los pasos que 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 personalizado y ventana acoplable.

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

declarativo parece ser la opción más preparada para el futuro y la que la gente recomienda. es el único que admite Visual Pipeline Editor. admite validación. y termina teniendo la mayor parte del poder de la secuencia de comandos, ya que puede recurrir a la secuencia de comandos en la mayoría de los contextos. En ocasiones, a alguien se le ocurre un caso de uso en el que no puede hacer lo que quiere con declarativo, pero generalmente se trata de personas que han estado usando secuencias de comandos durante algún tiempo, y es probable que estas brechas de funciones se cierren a tiempo.

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

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

Para citar: "Scripted Pipeline ofrece una enorme cantidad de flexibilidad y extensibilidad para 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 obstinada para autor de Jenkins Pipeline.

Los dos son fundamentalmente el mismo subsistema Pipeline ".

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

1. La canalización declarativa se define dentro de un bloque etiquetado como "canalización", mientras que la canalización con script se define dentro de un "nodo".
2. Sintaxis: la canalización declarativa tiene 'Etapas', 'Pasos'
3. Si la compilación falla, la declaración declarativa le da una opción para reiniciar la compilación desde esa etapa nuevamente, lo cual no es cierto en la opción programada
4. Si hay algún problema en la secuencia de comandos, el declarativo le notificará tan pronto como cree el trabajo, pero en el caso de la secuencia de comandos, pasará la etapa que está 'Bien' y arrojará un error en la etapa que es 'No está bien'

También puede referir esto. Una muy buena lectura -> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/ 2194470 / szymon-stepniak? Tab = perfil

La canalización declarativa es muy superior a la canalización con script . La canalización declarativa es capaz de ejecutar todo lo que la canalización con script puede realizar mediante el paso de guión y tiene muchas funciones adicionales.

Además, Declarative Pipeline tiene soporte para varias tecnologías como Docker o Kubernetes (ver aquí ).

La tubería declarativa también está más preparada para el futuro. Todavía está en desarrollo y se han agregado nuevas características como la función Matrix recientemente introducida a fines de 2019.

tl; dr - Declarative Pipeline puede hacer todo lo que puede hacer el Scripted Pipeline e incluso más.