Skip to content

Registrar el runner inicial

Con el workflow sincronizado en main y development y la imagen taller disponible, abrí tu repo en el navegador y una terminal nueva del host en lab. Desde ahí vamos a crear lab-runner y continuar en su Bash.

Este primer run va a comprobar el estado correcto antes de introducir el error. Lo llamamos baseline porque después vamos a comparar las otras ejecuciones con él. Usá una instancia nueva, sin reutilizar la configuración ni el token de una ejecución anterior.

Runner inicia una conexión saliente hacia GitHub y recibe jobs sin túnel

Diagrama del taller; ejemplo conceptual. El runner consulta GitHub con una conexión saliente. No necesita un túnel ni una red Docker propia.

Pantalla de GitHub para elegir Linux y arquitectura al registrar un self-hosted runner

Captura de referencia de la interfaz de GitHub, no prueba de tu registro.

En GitHub abrí Settings → Actions → Runners → New self-hosted runner. Elegí Linux y la arquitectura de tu imagen. El runner ya está descargado en taller; no repitas los comandos de instalación de esa pantalla. Buscá el token temporal de Configure.

Ese token temporal autoriza registrar el runner en este repo y tiene vencimiento. No es el PAT con el que autenticás gh en el host. No copies ese PAT dentro del runner ni lo uses para responder al registro.

Antes de crearla, mirá qué containers están activos desde el host:

docker ps

No debe seguir activo un lab-runner anterior. No reemplaces ni detengas runners ajenos. Si el nombre ya existe por una instancia de la práctica que no terminó, resolvé su estado antes de crear otra.

docker run --rm -it --name lab-runner taller

Dentro de esa nueva instancia, reemplazá sólo la URL por tu repo:

cd /opt/actions-runner
./config.sh --url https://github.com/TU_USUARIO/REPO \
  --name workshop-runner --labels workshop --ephemeral

El programa pide el token temporal de registro con entrada oculta. Pegá el de New self-hosted runner, nunca tu PAT. No lo pases por argumento ni variable de shell. Si venció, obtené otro en esa pantalla. Aceptá los valores sugeridos para grupo y carpeta de trabajo si aparecen. Si el nombre choca con un runner ajeno, no aceptes reemplazarlo.

Iniciá la escucha desde /opt/actions-runner:

exec ./run.sh

La terminal debe quedar esperando con un mensaje como:

Listening for Jobs

Buscá también el runner disponible en GitHub con self-hosted, linux y workshop. Cada opción cumple una parte distinta del cierre. --ephemeral le asigna un solo job y luego da de baja el runner. exec reemplaza la shell, de modo que al terminar el job sale el proceso principal del container. Entonces --rm elimina la instancia. No esperes volver a una shell dentro del runner al acabar.

No montes en este container el proyecto del host, el perfil de Hermes, la sesión de gh, el home del host ni el socket Docker. El checkout descarga el repo y el runner sólo necesita salida hacia GitHub y las descargas del job. Ejecutá únicamente código de la práctica que controles. El registro web no requiere Administration en el PAT.

No sigas si no está escuchando, tiene etiquetas distintas o configuraste otro repo. Dejá abierta esta terminal mientras iniciás la ejecución desde otra terminal del host o desde el navegador.