Construye, testea y publica tu aplicación Java con Github Actions

0
300
header picture from post

Índice

  1. Introducción
  2. Creando el Workflow
  3. Github Packages

Introducción

La idea de este post es crear un flujo de integración continua que ejecute los tests y haga un deploy de nuestro paquete en el registry de Github Packages.

Si estás empezando con Github Actions, te recomiendo leer antes el tutorial [Introducción a Github Actions. Sintaxis básica.]

El proyecto:

  • Spring boot con maven.
  • Base de datos postgres con una tabla users.
    postgres console
  • Un endpoint /users que devuelve una lista de usuarios. Actualmente solo tengo el usuario autentia con ID 1. Mi test de integración comprobará que el endpoint me devuelve una lista de usuarios de longitud 1.

  • Flyway como herramienta de migración de base de datos.
  • El plugin de maven docker-maven-plugin en el pom.xml para levantar mi contenedor de postgres en los tests de integración.

Github actions nos permite la Integración Continua (CI) y el Despliegue Continuo (CD) desde nuestros repositorios de Github.
¿Cómo funciona? un evento ejecuta un workflow, por ejemplo, un push a la rama master o un pull request, y ese workflow a su vez puede tener distintos jobs. Podemos tener un job para ejecutar nuestros tests y otro job para publicar la aplicación. Cada job utiliza steps que tiene diferentes tareas, más conocidas como actions. Podemos crear nuestras propias actions (por aquí te dejo este post) o utilizar las creadas por la comunidad. También podemos nombrar cada acción y dar una breve descripción de lo que hace usando la key name. Es importante saber que por defecto, los jobs se ejecutan en paralelo a menos que los configuremos para que se ejecuten de forma secuencial (cuando un job depende de otro).

workflow structure

Creando el workflow

En primer lugar, debemos crear nuestro workflow en .github/workflows.

folder structure

Comenzamos añadiendo un nombre al workflow y configurando el evento que lo lanzará. En este caso, el evento es un push a la rama master. Ahora necesitamos configurar los jobs para el workflow. El runs-on configura el job para que se ejecute en una máquina virtual de Github, en este caso, un runner de Ubuntu Linux (mas información aquí). En el ejemplo anterior, solo tengo un job publish que realiza los siguientes pasos:

  • La acción de checkout descarga una copia del repositorio en el runner.
  • La acción de setup configura el entorno Java. La key with nos permite especificar las variables de entrada de dicha ación. En el ejemplo especificamos la version del JDK y settings-path nos permite cambiar la ubicación del fichero settings.xml
  • Teniendo en cuenta que los jobs que se ejecutan en los runner se lanzan siempre en un entorno virtual nuevo, nos gustaría cachear ciertos ficheros o dependencias que no suelen cambiar con frecuencia para no tener que descargarlos cada vez que se lanza la acción. En el ejemplo anterior, estoy almacenando en caché todos las dependencias del repositorio m2. Es importante establecer una key para que la acción intente recuperar los archivos de caché en función de si el hash ha cambiado. Para crear la key, estoy usando la variable runner.os que me indica dónde se está ejecutando el job actual y la estoy concatenando con la función hashfile que devuelve un hash de los archivos especificados (más información aquí). He estado leyendo sobre cómo hacer un clean caché desde la interfaz sin tener que modificar la key del workflow directamente, y día de hoy, hay una issue abierta en github sobre esto. Hay un workaround y es usar secrets. Cada vez que actualicemos nuestro secret desde la interfaz, el workflow desechará la caché anterior y creará una nueva entrada. Otro punto a tener en cuenta es que GitHub eliminará cualquier entrada de caché a la que no se haya accedido en 7 días y el tamaño de caché está limitado a 5Gb.

secret tab from github

  • Voy a publicar el proyecto en Github Packages y para ello ejecuto mvn clean deployEs importante saber que la acción actions/setup-java@v1 crea automáticamente el fichero settings.xml con la autenticación del servidor como se ve a continuación. Para poder usar GITHUB_TOKEN, necesitamos referenciarlo en nuestro workflow, por eso lo vemos como variable de entrada en la acción Publish package. En caso de no hacerlo, obtendremos un 401 Unauthorized.

El servidor creado tendrá un id github, la variable de entorno GITHUB_ACTOR es nuestro nombre de usuario y la variable de entorno GITHUB_TOKEN es nuestra contraseña (estas variables de entorno existen en nuestro repositorio de github por defecto). En el pom.xml, solo necesito añadir la configuración del repositorio donde se va a subir.

Si hacemos un push, en la parte derecha de nuestro repositorio podemos encontrar el paquete subido.

package button github

Si hacemos click, podemos ver la dependencia.

dependency in github

  • Uno de los últimos pasos es subir el artefacto. Recordemos que un artefacto es un archivo o una colección de archivos generados durante la ejecución de un workflow. Lo primero es crear la carpeta myTarget y copiar el jar. La última acción upload-artifact@v2 recibe dos parámetros de entrada, el nombre del artefacto y los archivos que se subirán.

generated artifact

Si descargamos myPackage, y descomprimimos el zip, vemos el jar.

artifact file

Cuando hacemos el push a master, en la pestaña Actions podremos ver el workflow en ejecución. Si todo va bien y no hay ningún error, nos saldrá un tick en verde.

ran workflow

Cuando hacemos click en el workflow ejecutado, podemos ver el listado de jobs junto con las acciones que ha ejecutado. En mi ejemplo solo vemos un job que es publish.

listed actions

Si comprobamos los logs de la acción publish package, podemos ver cómo el contenedor de postgres se levanta correctamente al igual que el contexto de spring. Flyway realiza las migraciones pertinentes en base de datos y posteriormente se lanzan los tests.

postgres container started log

postgres docker container stop logspring context up and test passed

Github Packages

Github packages es un servicio de hosting que nos permite alojar nuestros paquetes de forma privada o pública y usarlos como dependencias en otros proyectos. Como vimos en la sección anterior, hemos subido el proyecto como dependencia a Github Packages. Pero, ¿cómo puedo instalar una dependencia de maven almacenada en el registry de github packages?. Además de añadir la dependencia en el pom.xml a <dependencies> como es lógico, debemos seguir los siguientes pasos:

  • En nuestro pom.xml, necesitamos apuntar al repositorio de github donde está la dependencia que queremos instalar.

  • El registry de github packages está disponible a través de la api de GitHub y necesita autorización, por lo que debemos añadir nuestras credenciales de github en el settings.xml. En mi caso las he añadido en mi settings global (~/.m2/settings.xml)

Para generar un token, podemos hacerlo desde Settings > Developer Settings > Personal access tokens y activar el permiso read:packages.

Una vez realizados estos pasos y si todo ha ido bien, la dependencia se instalará sin ningún problema 😃.

 

 

Dejar respuesta

Please enter your comment!
Please enter your name here