Mantener dependencias de nuestras aplicaciones no es tarea sencilla, sobretodo cuando tenemos un proyecto bastante grande con cientos de dependencias que puede convertirse en un verdadero dolor de cabeza y que implica un mayor esfuerzo en términos de tiempo.
Renovate nos facilita la automatización de dependencias de un proyecto en concreto, bastante similar a la aplicación Dependabot Sin embargo, Dependabot requiere que sea configurado mediante un proyecto de la comunidad para ser ejecutado en GitLab, Renovate se integra perfectamente con GitLab y está oficialmente soportado
En este tutorial vamos a instalar y configurar Renovate en GitLab, para que haga autodiscovery de nuestros repos/proyectos, manejo de Merge Requests a través de Issues, integrarlo con GitLab Container y Package Registry y merge automático de actualizaciones de pequeñas dependencias.
PROMO DigitalOcean#
Antes de comenzar, quería contarles que hay una promoción en DigitalOcean donde te dan un crédito de USD 200.00 durante 60 días para que puedas probar los servicios que este Proveedor Cloud ofrece. Lo único que tienes que hacer es suscribirte a DigitalOcean con el siguiente botón:
O a través del siguiente enlace: https://bit.ly/digitalocean-itsm
Prerequisitos#
GitLab Personal Access Token#
Necesitaremos un token personal de GitLab para poder configurar Renovate. Este token tener los siguientes permisos:
- read_user
- api
- write_repository
Para ellos iremos al menú a nuestro perfil en la esquina superior derecha, y seleccionamos la opción Preferencias:
Buscamos en el menu de la izquierda la opcion Tokens de Acceso:
Ahora vamos a darle un nombre a nuestro Token, para mantenerlo simple usaré Renovate y en la fecha de expiración alguna especifica con los permisos necesarios:
Copiamos nuestro Token y lo reservamos:
GitHub.com Personal Access Token (opcional)#
Es recomendable configurar un Token de GitHub con permisos mínimos para que el bot pueda hacer peticiones autenticadas a github.com, esto para descargar cualquier dependencia que utilice tags de GitHub y evitar llegar al máximo de llamadas a la API de github.com y que los jobs fallen.
Para configurar un token de GitHub se puede seguir esta documentación
GitLab Runner: Público vs Privado#
Se recomienda que se utilice un Runner privado dedicado para ejecutar los trabajos de Renovate, o al menos uno público en el que se pueda mantener los Logs de manera privada. Hoy dia, al ejecutar Renovate en Runners compartidos no resta minutos a los 400 de CI que nos entrega GitLab por mes. No obstante, esto puede cambiar en el futuro.
Si igual quieres instalar y configurar tu propio Runner, te dejo el siguiente articulo: Como Configurar y Utilizar GitLab Runner Self-Hosted
Instalando Renovate#
Para instalar Renovate, debemos hacer fork del proyecto en GitLab a traves del siguiente link: https://gitlab.com/renovate-bot/renovate-runner
En nuestro caso, he creado un grupo que se llama: Renovate Runner Example ( https://gitlab.com/renovate-runner-example/) y alli hacer fork del proyecto renovate-runner.
Vamos a configurar ahora dos variables de ambiente necesarias:
RENOVATE_TOKEN: Aquí colocaremos nuestro Token de GitLab.GITHUB_COM_TOKEN: Aquí colocaremos el token de GitHub.RENOVATE_EXTRA_FLAGS: Aqui vamos a colocar los argumentos con que queremos que se ejecute Renovate.
autodiscoverFilter para que el bot no se ejecute sobre cualquier proyecto que no pertenezca a nuestra cuenta. (--autodiscover=true --autodiscover-filter=grupo1/*) De todas formas, échale un vistazo a la documentación de Renovate para mas información de seguridad en GitLab.En caso que queramos que el bot se ejecute en cualquier proyecto donde el token de acceso nos permita, y además escanee aquellos donde Renovate no esté configurado, lo conseguiremos con este argumento: RENOVATE_EXTRA_FLAGS: --autodiscover=true --onboarding=true --autodiscover-filter=grupo1/*.
Y si deseamos especificar de manera manual aquellos repos sonde el bot se ejecute, agregamos este argumento delimitando cada proyecto por medio de un espacio: RENOVATE_EXTRA_FLAGS: group1/repo5 user3/repo1.
Vamos a configurar entonces las varibles que necesitamos, vamos al menú Configuración > CI/CD:
Expandimos la opción Variables y agregamos las variables de ambiente necesarias (RENOVATE_TOKEN, GITHUB_COM_TOKEN, RENOVATE_EXTRA_FLAGS), recordando marcar la opción Mask Variable:
Ahora lo que queda es programar a Renovate para que se ejecute cada cierto tiempo, lo vamos a configurar para que se ejecute 1 vez por día. Para esto vamos al menú CI/CD > Programaciones:
Y ahora presionamos el botón de Ejecutar:
En la opción de arriba nos lleva directamente al Pipeline en curso, sino podemos verlo en el Menú CI/CD > Trabajos:
En el log del job podemos ver que se ejecutó correctamente:
Agregando Proyecto de Ejemplo#
Voy a agregar un nuevo proyecto a este grupo, de tal forma que cuando Renovate se vuelva a ejecutar, lo que va a suceder es: Va a crear un nuevo Merge Request con un archivo renovate.json en el cual va a configurar el repositorio con la base minima y cualquier archivo que detecte intentará aplicar los cambios. Por ejemplo, un dockerfile con una versión antigua de alpine.
FROM alpine:3.10
apk upgrade --no-cache
ENTRYPOINT["sh"]
Volvemos a ejecutar el job programado en el repo de renovate-runner, y lo que sucede es que nos va a detectar el repositorio que hemos creado y también el Dockerfile:
En la próxima ejecución, nos creará un Merge Request con la actualización de la imagen de alpine como podemos ver en la siguiente salida:
Y si ahora vamos al proyecto, veremos el MR:
Conclusión#
Renovate es una gran alternativa para mantener las dependencias de nuestros proyectos actualizadas. Nos permite configurar de manera flexible el escaneo de repositorios y detectar el lenguaje de programación utilizado (nodejs, golang, python, etc.) para luego presentarnos un Merge Requests con los cambios y probarlos.
Espero les haya gustado y nos vemos en la próxima!