jenkins - Job DSL Plugin Vs Pipeline Plugin

jenkins-plugins jenkins-job-dsl

Question

¿Cuál es la principal diferencia entre Job DSL Plugin y Pipeline Plugin?

1. ambos proporcionan un camino para la creación programática de empleos
2. ¿Cuál es el mejor para seguir adelante y por qué?
3. Si ambos tienen una funcionalidad similar, ¿tienen diferentes casos de uso?
4. Dado que Jenkins 2.0 se está centrando en las tuberías como código, ¿significa esto que job-dsl no tiene futuro o que Pipeline Plugin es el siguiente paso en Job DSL Plugin?

Answer 1

Hay una distinción importante que no se ha mencionado aquí hasta ahora: las pruebas. Con el trabajo-dsl hay una forma de probar el código DSL antes de confirmarlo en SCM: https://github.com/sheehan/job-dsl-gradle-example : esto permite que se ejecute un conjunto de pruebas local en código DSL, así como en Jenkins, antes de que se ejecute el código. Hasta donde yo sé, no hay un equivalente en el enfoque de Pipeline nativo.

Answer 2

Mi respuesta preliminar basada en una experiencia muy limitada:

• Cada uno usa un DSL Groovy diferente.
• Job DSL le brinda una forma de crear otros trabajos de acuerdo con un script Groovy. Entonces, si desea un conjunto de trabajos relacionados con X (por ejemplo, una tubería), creará un trabajo DSL de trabajo, escribirá el script, ejecutará ese trabajo y luego tendrá esos trabajos X, más el que crea esos trabajos . En ese momento, solo el trabajo que creó directamente se ha ejecutado, los creados por ese trabajo no. OOTB, estos trabajos no están ocultos de la misma manera que los módulos Maven en un trabajo Maven multimódulo están ocultos, pero entiendo que hay al menos una forma de crear una vista y pegar los trabajos allí.
• Pipeline DSL simplemente se cuelga indefinidamente en los 2 entornos muy diferentes donde lo he probado. : ''(Según tengo entendido, este es un error conocido de showtopper: busque y encontrará algunos tickets de errores abiertos sobre esto. De todos modos, ejecutar el trabajo Pipeline que crea realmente ejecuta el pipeline, no genera un montón de trabajos como Job DSL Por lo tanto, los desencadenantes para ejecutar el trabajo de canalización son desencadenantes para ejecutar la canalización, no simplemente actualizar los trabajos que define.
• La canalización parece ser más utilizada, a juzgar por los números de descarga. Por supuesto, Pipeline es una característica predeterminada de Jenkins 2.0, que podría explicar el aumento reciente en las descargas. Los mantenedores de Jenkins seguramente quieren que lo uses .

En resumen: el DSL de Job DSL es para crear trabajos que forman una tubería, el DSL de Pipeline Plugin define la tubería en sí.

Y para responder a su (s) pregunta (s): Pipeline debería ser más compatible en el futuro, me parece más sencillo (el trabajo es un trabajo, no un metajob) y parece tener más funciones (incluido el flujo de trabajo). Lo usaría a menos que golpee el error showtopper de Doom mencionado anteriormente y no pueda encontrar una solución / solución.

Answer 3

Mi sensación es que el enfoque ideal es usar ambos. Pipeline es la nueva característica nativa de Jenkins para tener trabajos como código. Sin embargo, si construir Jenkins desde cero, esos trabajos aún deben crearse. Esto significa que Jenkins no puede ser 100% verdaderamente programado y construido a partir de código.

Lo que puede hacer es usar JOB DSL para construir la estructura esquelética de todos los trabajos, luego usar tubería para la implementación de los trabajos. Esto le permitirá ejecutar el script Jenkins al 100%, menos el trabajo inicial inicial que se creará.

Tal vez, eventualmente podamos usar la tubería para controlar completamente Jenkins (seguridad, configuración e incluso complementos). Pero hasta entonces, creo que es un buen enfoque utilizar DSL y Pipeline.

Answer 4

Tengo una amplia experiencia con ambos. Una respuesta concisa es que Job DSL ha existido durante mucho más tiempo y fue la solución de código abierto de Netflix para "codificar" Jenkins. Le permitía introducir lógica y variables en la secuencia de comandos de sus trabajos de Jenkins y, por lo general, uno usaría estos trabajos para formar algún tipo de "canalización" para un proyecto en particular. Este complemento recibió bastante tracción como una forma común de habilitar la creación de plantillas y secuencias de comandos de trabajo.

Jenkins Pipeline (2.0) es una nueva encarnación de un trabajo de Jenkins que se basa completamente en un DSL e intenta eliminar la necesidad de unir múltiples trabajos para llenar una sola tubería, que fue, con mucho, el uso más común de Job DSL. Originalmente, con Pipeline DSL no ofrece muchas de las características que Job DSL sí hizo, y como se mencionó anteriormente Job DSL le permitiría crear trabajos de Pipeline, podrían usarse juntos para definir una tubería.

Hoy, en mi opinión, hay pocas razones para usar Job DSL porque Pipeline es el mecanismo compatible con Jenkins para crear scripts de tuberías de Jenkins y ha cumplido o superado gran parte de la funcionalidad de Job DSL. Se están desarrollando nuevos complementos de forma nativa para Pipeline, y los desarrolladores de Jenkins están alentando a aquellos que no lo hacen a integrarse con Pipeline. Y Pipeline tiene varias ventajas:

• No hay necesidad de "inicializar" trabajos usando Pipeline como lo hay con Job DSL ya que Pipeline es el trabajo en sí mismo . Con Job DSL, es solo un script que crea otros trabajos .
• Con Pipeline, tiene características tales como un paso de entrada manual parametrizado, que le permite especificar la lógica de la secuencia intermedia dentro de la tubería
• La lógica que se puede incluir en un trabajo DSL se limita a crear los trabajos ellos mismos; mientras que con Pipeline puede incluir lógica directamente dentro del trabajo.
• Job DSL es simplemente mucho más difícil de crear una tubería de entrega básica usando, por ejemplo, el Complemento de tubería de construcción ; Usando Pipeline su archivo será más pequeño y la sintaxis más corta. Y si está utilizando Job DSL para crear trabajos de Pipeline, no he visto un valor importante para eso debido a las características de plantilla disponibles de fábrica con Jenkins Pipeline.

Finalmente, Jenkins Pipeline es, con mucho, la característica más frecuente de Jenkins en este momento. Consulte la agenda de Jenkins World 2016 y verá aprox. El 50% de las sesiones implican canalización. Ninguno para Job DSL.