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


95

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.


1
No veo nada sobre la desaprobación de secuencias de comandos, y eso sería alarmante teniendo en cuenta la brecha de características entre declarativa y secuenciada.
Matt Schuchard

Respuestas:


85

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


5
Intenté trasladar una serie de trabajos de canalización declarativa a canalización con script porque eran "una opción ideal para usuarios avanzados y aquellos con requisitos más complejos". Casi no hay documentación para la canalización con script. Ninguna. Es casi inútil así. Esta es una gran diferencia de la que la gente debería estar consciente.
cauchy

6
@cauchy existe la misma documentación tanto para pipelines con script como declarativos, pero como scripted es para usuarios avanzados, no es el que se muestra primero, pero toda la documentación incluye documentación y ejemplos de pipelines tanto con script como declarativos. Solo tiene que alternar la sintaxis cifrada debajo de cada ejemplo de documentación de canalización declarativa
Ilhicas

1
@Ilhicas donde? No hay "conmutadores" en el manual del usuario. ¿Tienes un enlace? Incluso los pasos de la canalización en la canalización con script simplemente dicen que no hay diferencias con la canalización declarativa y los enlaces a los documentos de la canalización declarativa, lo cual es engañoso.
cauchy

3
@cauchy ejemplo jenkins.io/doc/book/pipeline , a continuación hay un conmutador que va a jenkins.io/doc/book/pipeline/# , que expande el equivalente en
script

El problema radica en que no lee correctamente la documentación, "Aquí hay un ejemplo de un archivo Jenkins que usa la sintaxis declarativa de canalización; se puede acceder a su sintaxis con script equivalente haciendo clic en el enlace Alternar canalización con script a continuación:" ¡Esto está en la documentación oficial! Lea, entonces puede hacer tales declaraciones .. si son ciertas ..
Ilhicas

57

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.


3
¿Tiene algún ejemplo del uso de un bloque script () en una canalización declarativa? Ese vínculo no tiene ninguno.
user2023861

Si se encuentra usando varias veces un scriptbloque en una canalización declarativa, debería considerar usar una canalización con script hasta el final.
Kru

Mi preferencia es la canalización declarativa sobre las canalizaciones con script, como mencionó @CodyK. Sí, estoy de acuerdo en que hay algunas situaciones complejas en las que podemos usar pipelines con script. Pero, la planificación simplificada prope siempre reduce la complejidad y la mayoría de las veces allanará el camino hacia una tubería declarativa más simple.
NIK

18

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

1
Esta es la respuesta más útil que he visto en todo el año: D gracias
Trevor Rudolph

14

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/


4
No existe algo más a prueba de futuro, sirven a diferentes audiencias y propósitos y ambos tienen el mismo sistema subyacente, como se indica en muchas otras respuestas aquí. Declarativo limita al usuario, el script le da demasiada libertad, por lo que debe tener diferentes niveles de conocimiento de jenkins para aplicar cada uno.
Ilhicas

3
Estoy de acuerdo contigo. esta respuesta fue la mejor en el momento en que la escribí, pero me alegra que los autores de jenkins hayan documentado mejor las diferencias ahora y hayan dejado en claro que el guión no desaparecerá pronto. :)
burnettk

7

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
  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


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.