Herramientas de desarollo: Github Actions como CI para .Net Core

Tiempo de lectura: 6 minutos
Imagen ornamental con el logo de Github Actions para la entrada Herramientas de desarollo: Github Actions como CI para .Net

Después de unas semanas apasionantes hablando sobre código de alto rendimiento en .Net Core y de cómo escribir un logger de alto rendimiento acorde a las mejoras sobre el código, es hora de volver a la realidad del día a día.

Hace unos meses que quería hablar de Github Actions y .Net Core (o cualquier otro lenguaje) ya que me parece una herramienta de CI super interesante al estar integrada perfectamente en Github.

¿Qué es Github Actions?

Hace ya unos cuantos meses Github anunció que iba a introducir un sistema de integración y despliegue continuo. Unos pocos meses después se concedió acceso a una beta y en noviembre se anunció la disponibilidad general para el público.

Github Actions surgió como un ‘fork‘ de Azure Pipelines que poco a poco va evolucionando por su propio camino. Ahora mismo es como el hermano pequeño de los pipelines con una funcionalidad más «limitada» pero solo el futuro dirá en que se acaban convirtiendo.

¿Por qué es interesante Github Actions?

Aunque en esta entrada vayamos a hablar de Github Actions como herramienta para .Net Core, no está ligado a este ni mucho menos. Se puede utilizar con muchísimos lenguajes y para muchísimas finalidades.

Una pregunta que podemos plantearnos llegados a este punto es que aporta este sistema de CI/CD en concreto si tenemos ya otros que hacen la misma labor. Sin ir más lejos en este blog hemos hablado sobre cómo hacer CI/CD con Azure Pipelines, o cómo hacer integraciónes en Travis CI y Appveyor.

La respuesta al igual que en otros muchos casos es la sencillez que aporta tener todo en una herramienta unificada. Históricamente Github ha sido un repositorio público de código fuente, pero ha ido añadiendo paulatinamente como las tablas de kanban que permiten guiar el desarrollo del código con metodologías ágiles. Con esta nueva funcionalidad Github se ha convertido en una suite completa que permite la gestión integral del proyecto desde un punto unificado.

Vale vale, mucha teoría. ¿Cómo pongo en marcha un flujo de trabajo con Github Actions para .Net Core.

La verdad es que es algo extremadamente sencillo ya que Github Actions utiliza un yaml muy parecido al de Azure Pipelines, por lo que, si habitualmente trabajas con este último, no debería ser ningún esfuerzo crear un workflow de Github Actions para .Net Core.

Creando un workflow de Github Actions para .Net Core

Lo primero que vamos a tener que hacer para crear un workflow de Github Actions para .Net Core es pulsar sobre el botón ‘Actions‘ que se encuentra en el panel superior del repositorio.

La imagen señala con una flecha el botón de Actions en el panel de herramientas de Github.

Una vez hecho eso basta con que seleccionásemos el workflow de Github Actions para .Net Core (o el lenguaje que usemos).

La imagen señala el botón "set up this workflow" de .Net Core dentro del menu de Github Actions

Con este paso tan sencillo, vamos a comprobar que Github ya nos ofrece un template listo para poder funcionar:

name: .NET Core

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.101
    - name: Build with dotnet
      run: dotnet build --configuration Release

En fichero consta de 2 grandes secciones, las condiciones de ejecución y los jobs a ejecutar (la primera línea indica el nombre del workflow en la visualización).

La primera sección está dentro de la etiqueta on: e indica en qué casos debe ejecutarse el workflow, en este caso nos ofrece ejecutarse en cada push o pull request a la rama master, pero si queremos que se ejecute siempre en cualquier rama podríamos cambiarlo por algo como esto:

on: [push, pull_request]

Al no indicarle parámetros, se ejecutará en esos casos sin condiciones.

>Existen una gran cantidad de eventos disponibles, no solo relativos al código sino a otros muchos eventos de Github, te recomiendo leer la lista completa por si algún otro te resulta interesante.

La segunda sección son los trabajos en si que se han de realizar. En este caso estamos creando un único job que se ejecutará sobre ubuntu e instalará .Net Core 3.1.101 y después realizará la compilación.

Evidentemente este trabajo no está completo ya que faltan cosas como las pruebas, empaquetar el código para poder publicarlo, generar cobertura, y cualquier otra cosa que pudiésemos necesitar durante el proceso.

En este caso, vamos a simplemente añadir la ejecución de las pruebas añadiendo dentro de steps:

- name: Test with dotnet
  run: dotnet test --configuration Release

Simplemente estamos indicando que dentro de los pasos que tiene que ejecutar el job se ejecuten también las pruebas.

Probando nuestras Github Actions para .Net Core en múltiples plataformas

En estos momentos ya tenemos una integración perfectamente funcional con Github Actions para un proyecto .Net core (o del lenguaje que sea con unos mínimos cambios). El problema aquí es que .Net Core es multiplataforma y como tal deberíamos probarlo en varias plataformas para garantizar que funciona correctamente.

Para solventar este problema podríamos simplemente copiar y pegar el trabajo y cambiar la clave runs-on: pero se quedaría un poco feo ¿no? Aquí al igual que ocurre en otros sistemas de integración podemos aplicar matrices de variables que utilizará el trabajo para conseguir así reutilizar el código.

Vamos a definir una estrategia (strategy) dentro del job justo encima de los steps y dentro vamos a definir una matriz con una variable que indicará el tipo de agente donde debe ejecutarse el trabajo.

strategy:
  matrix:
    agent: ['windows-latest','ubuntu-latest','macos-latest']

Después, vamos a modificar la clave runs-on y vamos a hacer que, en vez de un literal, reciba esa variable. Para indicar una variable en Github Actions vamos a necesitar indicar el nombre de la variable dentro de ${{x}}.

runs-on: ${{matrix.agent}}

Con estos dos pequeños cambios hemos conseguido que nuestro trabajo de integración se ejecute tanto en Windows como en Linux como en MacOs. Basta con hacer el commit para poder encontrarnos con que ya se ejecutan los 3 trabajos.

La imagen muestra una vista de la interfaz de Github para un workflow de Github Actions para .Net Core donde se ejecutan 3 trabajos, uno en cada plataforma

Es posible si queremos clarificar los elementos utilizar la clave name para indicar un nombre especifico en vez del nombre por defecto. Por ejemplo, podemos añadir al trabajo

name: Example executed over ${{matrix.agent}}

Con ese sencillo cambio utilizando la misma variable con la que seleccionamos el agente, vamos a tener un cambio en la visualización consiguiendo poner un mensaje más específico.

La imagen muestra la visualización con el mensaje especifico "Example executed over" y el sistema operativo del agente para cada uno de los 3 casos

Por último, al igual que otros sistemas de integración, Github Actions dispone de un sistema de badges con el que poder reflejar el estado del trabajo en diferentes sitios como puede ser el readme del proyecto. Esto se puede conseguir desde el botón ‘Create status badge‘ dentro de la vista de Github Actions.

La imagen señala el botón 'Create status badge' en la parte derecha de la interfaz de usuario de Github Actions

Conclusión

Aunque Github Actions es una característica de Github muy nueva y que llega a un mercado en el que ya hay otros muchos sistemas establecidos, es una herramienta perfectamente integrada con Github. Esto facilita mucho la labor de gestión centralizada de todos los elementos de un proyecto y es algo a tener en cuenta.

Aunque ahora mismo es la versión ‘pequeña’ de Azure Pipelines, tiene multitud de acciones ya disponibles que suplen la mayoría de los casos (de hecho existe hasta un buscador). Precisamente por eso es una herramienta muy interesante a la que puede ser muy útil seguir la pista, ¿no crees?

Cómo es habitual, he creado un repositorio en Github (donde sino para usar Github Actions) con el código del proyecto para poder probarlo y trastear con el workflow.

Si te has quedado con ganas de más, he escrito otra entrada hablando sobre la nueva característica que han añadido para aprobaciones manuales:

Añadiendo aprobaciones manuales en despliegues con Github Actions

Deja un comentario