A la hora de automatizar la ejecución de los jobs de Jenkins encargados de gestionar la integración continua de las aplicaciones, se disponen de multitud de opciones y en el presente articulo se pretende detallar como utilizar los WebHooks de Bitbucket para ello.
Caso de uso
Se dispone en Jenkins, de un job de tipo “Pipeline“, encargado de desplegar distintos microservicios al realizar un push sobre el repositorio de Bitbucket correspondiente. La lógica del pipeline está contenida en un JenkinsFile y almacenada también en Bitbucket.
Build Token Root Plugin
Una manera de conectar Bitbucket y Jenkins es hacer uso de las ejecuciones remotas de este último. Dado que para ello es necesario disponer de un token de autenticación y desde BitBucket no es posible obtenerlo, la solución pasa hacer uso del plugin Build Token Root Plugin de Jenkins. Este plugin permite invocar jobs de manera remota, vía HTTP, sin necesidad de autenticación.
Una vez instalado, es hora de habilitar en el job de Jenkins la opción de “Lanzar ejecuciones remotas (ejem: desde ‘scripts’)“. Para ello, se debe establecer un identificador de seguridad, con el fin evitar que cualquiera pueda invocarlo. Una posibilidad es utilizar un UUID, que puede generarse online en uuidgenerator.net.
Finalmente es el momento de configurar el repositorio de BitBucket que alberga el código fuente del microservicio para lanzar un Post WebHook con cada commit.
La URL de Jenkins a introducir será la misma que una ejecución remota convencional, añadiendo el prefijo “buildByToken” a la URL, con el fin de evitar la necesidad de introducir un token. (El plugin soporta también la opción de pasar parametros al job)
A modo de ejemplo, se ha configurado el repositorio para no lanzar un WebHook con cada commit a las ramas “master” y “feature“.
Conclusiones
En conclusión, con el Build Token Root Plugin es posible lanzar ejecuciones remotas de jobs de Jenkins sin necesidad de un token de autorización.
Esto a su vez, a diferencia de otras soluciones como el plugin de Bitbucket, permite tener un único job de tipo “pipeline”, que se puede almacenar también en el SCM, re-utilizable para el despliegue de distintos microservicios.
Mikel's TechBlog 