Empezando a trabajar con GitHub Actions

La necesidad de tener automatizado nuestra integración (CI) y nuestros despliegues, creo que es algo ya fuera de toda duda. Seguro que habéis oído hablar de muchas herramientas, y queremos hablaros de una de ellas para vuestros repositorios GitHub, que es la reciente (aunque ya lleva un tiempo) GitHub Actions. 

Así pues, por si aún no ha quedado claro, GitHub Actions es la herramienta para automatizar flujos de CI/CD de nuestros repositorios GitHub. Pero ¿por dónde empezamos a trabajar con GiHub Actions? 

GitHub Actions pricing

Bueno, lo primero que seguro que a muchos os preocupa es: ¿Cuánto cuesta? La mejor noticia es que es gratis para empezar a trabajar. Con todas las cuentas de GitHub, tenemos hasta 2000 minutos de trabajo al mes, que básicamente se computa sumando el tiempo de ejecución de todos nuestros flujos al mes. A partir de aquí, si necesitamos más, podemos pasar a cualquiera de los planes de pago de GitHub para sacar el mayor partido. Y ahora que ya hemos hablado de los asuntos del dinero, vamos a empezar. 

Introducción GitHub Actions

Van a ser varias cosas las que necesitemos para empezar a trabajar con GitHub actions: 

1. Una cuenta y un repositorio de GitHub, obvio, ¿no?
2. Ficheros YAML de definición de nuestros flujos de trabajo, dentro del repositorio. 
3. Un agente de compilación de GitHub. 

Los YAML de definición de workflows en GitHub Actions

Probablemente, ya os hayáis topado en vuestra vida como desarrollador con ficheros YAML antes. Estos ficheros, cuya estructura se basa en espacios y/o tabulaciones, nos permite definir nuestro flujo de CI/CD. A fin de cuentas, estos flujos son una serie de acciones que se ejecutan en una determinada secuencia, para generar nuestras aplicaciones (ya sean binarios o por ejemplo contenedores Docker) y, posteriormente, desplegarlos. 

GitHub Actions define una estructura de YAML para ejecutar estas secuencias. Por convención, guardaremos estos ficheros en nuestro repositorio, bajo la carpeta .github/workflows y podremos tener tantos como queramos dentro de nuestro repositorio. Un ejemplo de un fichero muy (pero que muy) básico para generar una aplicación .NET Core, podría ser esto: 

En este sencillo ejemplo vemos las siguientes partes: 

1. Definimos el nombre de nuestro flujo (.NET) 
2. Definimos que eventos dentro del repositorio van a provocar la ejecución de este Workflow (más información) 
3. Y a continuación, definimos la colección de trabajos, en este caso solo uno: build. Que a su vez tiene la siguiente estructura: 
   1. El agente (del que hablaremos más adelante) donde se va a ejecutar la secuencia de pasos, en este caso Ubuntu-latest. 
   2. Las acciones típicas de una aplicación .NET Core, que son las tareas a ejecutar: Setup del framework (5.0) de .NET Core, dotnet restore de sus dependencias, dotnet build, y, por supuesto, la ejecución de test. 

Como os decía, tienen que estar en el directorio predeterminado estos ficheros YAML, pero el modo más sencillo de crearlos es a través del interfaz web de GitHub. Desde la home de nuestro repositorio, pulsaremos en Actions y a continuación en new workflow. 

Al crear un Workflow, existen plantillas predefinidas de Actions, pero también podemos empezar uno de cero. Si escogemos la de .NET Core, que es el ejemplo anterior, se nos mostrará una ventana de edición: 

Desde aquí, iremos editando el fichero y añadiendo la secuencia de tareas que queramos. Fijaros en la parte de la derecha. Tenemos tareas ya creadas por el propio Github o terceras partes para hacer todo lo que necesitemos: generar contenedores Docker, publicar artefactos, despliegues a cualquiera de las nubes principales… Pero bueno, ya os iremos hablando de flujos y tareas en otros artículos. Si queréis ver más sobre la sintaxis de YAML, podéis consultarlo. 

Con suerte, y un poco de trabajo, tendremos nuestro fichero YAML que compilará (y opcionalmente desplegará) nuestra aplicación. Pero antes ¿no hablamos de qué necesitábamos un agente? 

Agentes de compilación y despliegue en GitHub Actions

Como decíamos inicialmente, y como veíamos en el YAML, necesitamos un agente donde se ejecutan todos estos pasos. En el ejemplo, teníamos en la línea 12 esto: runs-on: ubuntu-latest. Esto dirá al motor de GitHub Actions, que los pasos de ese trabajo se tienen que ejecutar en una máquina Ubuntu, pero ¿de dónde sale esa máquina? 

La buena noticia es que el propio GitHub pone a nuestra disposición, dinámicamente, diversos agentes de compilación que podemos escoger para ejecutar nuestros flujos, y estos son: 

• Windows Server 2019: Windows-latest o Windows-2019 
• Ubuntu 20.04: Ubuntu-latest o Ubuntu-20.04 
• Ubuntu 18.04: Ubuntu-18.04 
• Ubuntu 16.04: Ubuntu-16.04 
• macOS Big Sur 11.0: macOS-11.0 
• macOS Catalina 10.15: macOS-latest o macOS-10.15 

Todos estos agentes tienen una serie de características técnicas de hardware y de software instalado, que podéis consultar. Pero aún así, si esos agentes no satisfacen vuestras necesidades por hardware o software, podéis también instalar el agente de GiHub Actions en vuestros propios entornos. Aquí os dejamos las instrucciones creando lo que se llama un self-hosted runner. 

Hay mucho más acerca de GitHub Actions, por ahora, queríamos daros esta serie de conceptos iniciales para que podáis empezar a probarlos. Así como este enlace, donde tenéis instrucciones detalladas y ejemplos. 

Si quieres profundizar más sobre las herramientas de GitHub, tienes la oportunidad de hacerlo revisando el webinar «Tus primeros pasos con GitHub»