Crear tu primer workflow file en GitHub Actions es el paso inicial para automatizar tareas en tu repositorio. Aquí descubrirás cómo estructurar el archivo YAML, qué hace cada etiqueta y cómo conectar un script de Python que imprima un hola mundo personalizado con tu usuario de GitHub.

Este recorrido es ideal si recién empiezas con automatización y quieres entender, línea por línea, cómo se construye un workflow funcional siguiendo un reto guiado en un repositorio base.

¿Cómo se estructura el script de Python para el reto?

La idea es mantenerlo simple pero personalizado. En la raíz del repositorio se crea un archivo llamado holamundo.py que importa la librería OS de Python para acceder a variables de entorno del sistema operativo donde corre el script [01:30].

Dentro del archivo se define una función main que crea una variable llamada nombre, la cual lee la variable de entorno username. Esa variable la inyectará después el workflow file. El print final muestra algo como Hola, Juan, desde GitHub, lo que confirma que la información viajó correctamente desde el workflow hasta el script.

python import os

def main(): nombre = os.environ.get('username') print(f"Hola, {nombre}, desde GitHub")

if name == 'main': main()

El condicional if __name__ == '__main__' asegura que la función main solo se ejecute cuando el archivo se llama directamente, no cuando se importa desde otro módulo.

¿Para qué sirve la librería OS en este script? Permite acceder a variables de entorno del sistema donde corre el script, en este caso para leer el username que el workflow inyecta en tiempo de ejecución.

¿Qué significa cada etiqueta del workflow file en YAML?

El archivo se llama hola-mundo.yml y respetar ese nombre exacto es crítico: si cambias mayúsculas, guiones por guiones bajos o la extensión, los actions del repositorio no reconocerán que completaste el reto y no desbloquearán los siguientes [05:30].

¿Qué hacen name y run-name?

La etiqueta name define el nombre del workflow tal como aparecerá en la pestaña Actions de GitHub. Es opcional, pero sin ella verías solo la ruta del archivo, algo como .github/workflows/holamundo.yml, lo cual se vuelve difícil de leer cuando tienes muchos workflows [07:00].

La etiqueta run-name asigna un título a cada ejecución específica del workflow. Si no la defines, GitHub usa la ruta del archivo o el nombre del commit que disparó la ejecución [08:30].

¿Qué controla la etiqueta on?

La etiqueta on define el trigger, es decir, el evento que dispara el workflow. En este caso el valor es push, lo que significa que correrá cada vez que se haga un push a cualquier rama del repositorio [09:30]. YAML acepta dos notaciones: lista entre corchetes [push] o lista vertical con guiones.

¿Cómo se organizan los jobs y steps?

La etiqueta jobs agrupa todos los trabajos del workflow. Cada job lleva un nombre interno (sin espacios, solo letras y guiones) y dentro define:

• runs-on: especifica el runner, en este caso ubuntu-latest, que puede ser Ubuntu, macOS o Windows gestionado por GitHub, o un runner propio.
• steps: agrupa la secuencia de pasos del job.
• name: nombre opcional pero recomendado para identificar cada paso.

Cada step puede ejecutar un action con la etiqueta uses o un comando de terminal con la etiqueta run [11:30].

¿Cómo se conectan los tres pasos del job?

El primer paso usa el action actions/checkout@v3, uno de los más comunes, que clona el repositorio dentro de la máquina virtual del runner para que los siguientes pasos accedan al código.

El segundo paso ejecuta un comando que crea la variable de entorno username tomando el valor de github.actor (tu nombre de usuario) y la envía a las variables compartidas entre pasos del mismo job. Todos los pasos de un mismo job corren en el mismo runner, así que comparten información [13:30].

El tercer paso ejecuta python holamundo.py, y gracias a la variable definida antes, el script imprime el saludo personalizado.

¿Qué diferencia hay entre uses y run en un step? uses ejecuta un action reutilizable de GitHub o de la comunidad, mientras que run ejecuta directamente un comando en la terminal del runner.

¿Qué pasos agrega GitHub automáticamente al ejecutar el workflow?

Al entrar a la pestaña Actions y revisar la ejecución, verás pasos que tú no escribiste: set up job, post checkout y complete job. GitHub los agrega automáticamente para preparar el runner, autenticar, traer archivos y luego limpiar todo lo que se creó durante la ejecución [16:30].

Los pasos que usan actions suelen tener un post asociado que limpia recursos. Los pasos que solo corren comandos no tienen limpieza automática individual; eso lo gestiona el complete job.

En los logs puedes inspeccionar cada paso:

1. Checkout: muestra la versión de Git, autentica y copia los archivos.
2. Definir variable: ejecuta el comando echo y reemplaza github.actor por tu usuario real.
3. Correr script: ejecuta Python e imprime el saludo final con tu nombre de usuario.

Con esta base ya tienes un workflow file funcional. Compártelo en los comentarios para que tus compañeros vean cómo lo resolviste y comparen enfoques.