snippet - jenkinsfile generator

Jenkins Pipeline Jenkinsfile: directivas ''node'' y ''pipeline''

Question

Estoy empezando con Jenkins declarativa Pipeline . De algunos de los ejemplos que he visto, me doy cuenta de que el archivo Jenkins está configurado con la directiva Pipeline:

pipeline {
agent any
stages {
stage(''Build'') {
steps {
sh ''make''
}
}
stage(''Test''){
steps {
sh ''make check''
junit ''reports/**/*.xml''
}
}
stage(''Deploy'') {
steps {
sh ''make publish''
}
}
}
}

En otros ejemplos, observo que el archivo Jenkins está configurado con una directiva de nodo:

node {
stage ''Checkout''
checkout scm
stage ''Build''
bat ''nuget restore SolutionName.sln''
bat "/"${tool ''MSBuild''}/" SolutionName.sln /p:Configuration=Release /p:Platform=/"Any CPU/" /p:ProductVersion=1.0.0.${env.BUILD_NUMBER}"
stage ''Archive''
archive ''ProjectName/bin/Release/**''
}

No he podido encontrar documentación sólida sobre cuándo y por qué usar cada uno de estos. ¿Alguien tiene alguna información sobre por qué difieren y cuándo es apropiado usar alguno de ellos?

No estoy seguro, pero creo que la directiva ''nodo'' se usa en una canalización con script en lugar de una tubería declarativa.

Gracias de antemano por cualquier orientación.

Answer 1

sí, un node nivel superior implica canalización con secuencias de comandos, y un canal de nivel superior implica canalización declarativa.

declarativo parece ser la opción más a prueba de futuro y la que la gente recomienda, como en esta publicación de la lista de usuarios de jenkins donde un colaborador principal dice "ir declarativo". es el único que puede soportar el Editor de Visual Pipeline. Es compatible con la validación. y termina teniendo la mayor parte del poder de los scripts, ya que puede recurrir a los scripts en la mayoría de los contextos. de vez en cuando a alguien se le ocurre un caso de uso en el que no puede hacer exactamente lo que quiere hacer con declarativo, pero generalmente se trata de personas que han estado usando scripts durante algún tiempo, y es probable que estas brechas de características se cierren a tiempo. y finalmente, si realmente tiene que rescatar a uno u otro, escribir un traductor programático de declarativo a guión sería más fácil que al revés (más o menos por definición, ya que la gramática está más restringida).

Más contexto sobre las ventajas de la declaración del blog de disponibilidad general: https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/

Los documentos más oficiales que pude encontrar mencionan ambos (hasta el 21 de junio de 2017): https://jenkins.io/doc/book/pipeline/syntax/