Introducción
GitHub Actions es un sistema de automatización de workflows integrado en GitHub. Reacciona a eventos del repositorio, como pushes, pull requests o triggers manuales, y luego ejecuta automáticamente los jobs definidos.
Esta automatización puede realizar muchas tareas de DevOps, como probar código, compilar artefactos y desplegar aplicaciones. La lista de instrucciones se denomina workflow.
En un nivel más general, un workflow es la definición de un pipeline. Convierte los eventos del repositorio en una automatización repetible, de modo que la misma secuencia no dependa de que una persona recuerde ejecutarla correctamente cada vez.
En este laboratorio, escribirá el primer manual de instrucciones (workflow) para este robot. Aprenderá los cuatro componentes básicos de todo workflow:
- Triggers: ¿Cuándo debe despertarse el robot? (Por ejemplo, cuando hace push del código).
- Jobs: ¿Qué tarea principal debe realizar el robot?
- Runners: ¿Qué equipo debe utilizar el robot para realizar el trabajo?
- Steps: ¿Qué comandos específicos debe ejecutar el robot?
Al finalizar este laboratorio, tendrá un pipeline funcional que imprimirá automáticamente un saludo cada vez que actualice el código.
Requisitos previos
GitHub Actions es importante porque el desarrollo y la entrega modernos de software dependen de una automatización repetible, en lugar de depender de hacer clic manualmente y recordar los pasos.
Crear un repositorio
Para empezar a utilizar GitHub Actions, primero necesita un proyecto en GitHub. Crearemos un repositorio nuevo para este módulo. Utilizará este repositorio en varios laboratorios, así que siga cuidadosamente la convención de nombres.
Abra el navegador web e inicie sesión en GitHub. Haga clic en el icono +, situado en la esquina superior derecha de cualquier página de GitHub, y seleccione New repository.
En el campo «Repository name», escriba github-actions-basics. Si configura el repositorio como Public, será gratuito y fácil de utilizar. Marque la casilla Add a README file para inicializar el repositorio con un archivo. Por último, haga clic en el botón Create repository.
Ahora que el proyecto existe en la nube (GitHub), debe traer una copia a este entorno de laboratorio para trabajar con ella. Este proceso se denomina clonación.
En el terminal que aparece debajo, utilice el comando git clone. Debe reemplazar your-username por su nombre de usuario real de GitHub.
cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
Cuando termine el proceso de clonación, verá una carpeta nueva llamada github-actions-basics. Acceda a este directorio para empezar a trabajar.
cd ~/project/github-actions-basics
GitHub Actions aplica una regla estricta sobre la ubicación de las instrucciones. Solo busca una carpeta oculta específica llamada .github que contenga una subcarpeta llamada workflows. Si coloca los archivos de workflow en cualquier otro lugar, el asistente robot simplemente los ignorará.
Cree esta estructura de directorios obligatoria. La opción -p indica al comando que cree a la vez los directorios padre y secundarios si todavía no existen.
mkdir -p .github/workflows
A continuación, cree un archivo vacío llamado main.yml dentro de esta carpeta nueva. En este archivo escribirá las instrucciones.
touch .github/workflows/main.yml
Puede verificar que la configuración sea correcta mostrando los archivos de forma recursiva. Debería ver la carpeta .github, que contiene workflows, y dentro de ella, main.yml.
ls -R .github
Definir el trigger
Los archivos de workflow se escriben en YAML. Es un formato de texto sencillo que utiliza la sangría (espacios) para organizar la información, de forma similar a un esquema que usa sangría.
Todo workflow necesita un nombre y un trigger. El trigger indica al robot cuándo debe empezar a trabajar. Sin un trigger, el workflow nunca se ejecutaría. Queremos que el robot se despierte cada vez que hagamos push de código nuevo al repositorio.
Este modelo basado en eventos es una de las ideas principales de los sistemas de CI/CD. Los pipelines reaccionan a los cambios en el ciclo de vida del software en lugar de esperar a que alguien ejecute scripts manualmente.
Abra el archivo vacío main.yml con el editor de texto nano.
nano .github/workflows/main.yml
Escriba el siguiente contenido en el archivo.
name: First Workflow
on: push
La palabra clave name asigna al workflow una etiqueta que aparece en GitHub. La línea on: push es el comando clave. Significa: «Cuando ocurra un push, ejecute esto».
Presione Ctrl+X, después Y y, por último, Enter para guardar los cambios y salir del editor.
Definir el job y el runner
Ahora que el robot sabe cuándo despertarse, debe indicarle dónde trabajar. Esto se hace definiendo un Job y un Runner.
Un Job es una agrupación de tareas. Puede tener varios jobs, como «Probar código» y «Desplegar aplicación», pero por ahora solo tendrá uno.
Un Runner es el servidor que GitHub proporciona para ejecutar el job. Piense en él como el equipo frente al que se sienta el asistente robot. Utilizaremos ubuntu-latest, lo que significa que GitHub nos proporcionará un equipo nuevo con la versión más reciente de Ubuntu Linux.
Este runner nuevo es importante porque los jobs de un workflow deben ser reproducibles. Cada ejecución comienza en un entorno limpio, en lugar de depender de los restos de una configuración manual anterior.
Abra de nuevo el archivo main.yml.
nano .github/workflows/main.yml
Añada las siguientes líneas al final del archivo. Preste mucha atención a la sangría. En YAML, la sangría es fundamental. La palabra first-job debe tener dos espacios de sangría y runs-on, cuatro espacios.
jobs:
first-job:
runs-on: ubuntu-latest
El archivo completo debería tener ahora el aspecto del bloque siguiente. Asegúrese de que la estructura coincida exactamente.
name: First Workflow
on: push
jobs:
first-job:
runs-on: ubuntu-latest
Guarde el archivo y salga del editor (Ctrl+X, Y, Enter).
Añadir steps y hacer push
Ya tenemos el «cuándo» (on push) y el «dónde» (ubuntu-latest). Ahora llega la parte más importante: el «qué». Esto se define en la sección Steps.
Los steps son los comandos que ejecutará realmente el robot. En este primer laboratorio, solo le pediremos al robot que diga hola. Utilizaremos la palabra clave run para ejecutar un comando estándar de Linux.
Abra main.yml una última vez.
nano .github/workflows/main.yml
Añada la sección steps debajo de first-job. Asegúrese de que steps: quede alineado verticalmente con runs-on:.
steps:
- name: Print greeting
run: echo "Hello World from LabEx"
El guion - indica un elemento de una lista. Estamos enumerando los steps del job.
El archivo final debe tener exactamente este aspecto:
name: First Workflow
on: push
jobs:
first-job:
runs-on: ubuntu-latest
steps:
- name: Print greeting
run: echo "Hello World from LabEx"
Guarde el archivo y salga del editor.
Ahora que el manual de instrucciones está completo, debe enviarlo a GitHub. El robot solo consulta el código que está en GitHub, no el código de su equipo local.
Ejecute los comandos estándar de Git para guardar y cargar los cambios.
git add .
git commit -m "Add my first workflow"
git push
El sistema le pedirá su nombre de usuario y contraseña de GitHub.
Importante: Si aparece un error que indica que se eliminó la compatibilidad con la autenticación mediante contraseña, debe utilizar un Personal Access Token (PAT) en lugar de la contraseña de su cuenta. Puede generar uno en GitHub, en Settings -> Developer settings -> Personal access tokens. Seleccione «Tokens (classic)», genere un token nuevo con el alcance repo y pegue ese token en el terminal cuando se le solicite la contraseña.
Cuando el push se complete correctamente, vuelva al navegador. Acceda a la página de su repositorio y localice la pestaña Actions en la parte superior.
Debería ver un workflow llamado «First Workflow». Puede mostrar un círculo amarillo girando (en ejecución) o una marca de verificación verde (correcto). Haga clic en él. Dentro, haga clic en first-job para consultar los detalles. Puede expandir el step «Print greeting» para ver el mensaje «Hello World from LabEx» en los registros.
Resumen
¡Enhorabuena! Ha creado y ejecutado correctamente su primer workflow de GitHub Actions.
En este laboratorio, ha aprendido los cuatro pilares de un archivo de workflow:
- Trigger (
on): Indica a la acción cuándo debe comenzar. - Job: Agrupa las tareas.
- Runner (
runs-on): Especifica el entorno del servidor. - Step: Define el comando que se debe ejecutar.
Ahora tiene un «asistente robot» activo que supervisa su repositorio. En los próximos laboratorios, enseñaremos a este asistente a realizar tareas más útiles, como probar el código automáticamente.
