Prueba de trabajos y tuberías de Jenkins

10

Actualmente, tenemos un buen número de trabajos y canalizaciones de Jenkins para compilaciones, pruebas, implementaciones y otras actividades automatizadas.

Cada vez que cambiamos o agregamos un nuevo trabajo, solo lo probamos manualmente, por ejemplo, revisando el "camino feliz" (cuando el trabajo se realiza sin errores), probando un par de casos de prueba negativos cuando falla un trabajo o una tubería, verificando el Código de error y notificaciones.

Este enfoque claramente no es confiable y no escala bien. ¿Cómo podemos mejorar este proceso? ¿Existe un lugar para la automatización de pruebas cuando se trata de verificar cómo funcionan los trabajos y las tuberías de Jenkins?

alecxe
fuente
55
bienvenido a devops de alto nivel: ¿quién prueba la prueba? Creo que podría comenzar con un entorno de espacio aislado para replicar la configuración general del sistema y evolucionarlo para completar la configuración como enfoque de código; esto incluye configuraciones de trabajo mantenidas por código.
Peter Muryshkin

Respuestas:

10

Estoy publicando esto aquí no porque respalde estas soluciones (de hecho, nunca las he probado), sino solo porque son una respuesta potencial a su pregunta:

Puede comenzar con JenkinsPipelineUnit , un marco de prueba de unidad para scripts de Pipeline.

También hay un proyecto llamado jenkinsfile-runner que ejecuta su Jenkinsfile en una instancia transitoria y sin cabeza de Jenkins. Supuestamente, esto se puede usar para pruebas de integración de bibliotecas compartidas Jenkinsfiles y Pipeline. Sin embargo, a partir del verano de 2018 no hay documentación sobre cómo usar esta herramienta para las pruebas de integración, y no he podido encontrar ningún ejemplo de alguien que use esta herramienta "en la naturaleza".

Consulte también el informe de error relacionado en el JIRA de Jenkins: "Marco de prueba para Jenkinsfile" .

jayhendren
fuente