Comprobar la corrección y cerrar el runner

Con el tercer runner escuchando y el SHA corregido publicado, seguí desde el navegador y la terminal del host en lab, en la rama development. Vamos a comprobar la corrección y después cerrar el runner.

Elegí un solo dispatch. En la web, abrí Actions → Checks del workshop → Run workflow → development → Run workflow. Como alternativa, con permiso Actions: Read and write, ejecutá desde el host:

gh workflow run checks.yml --ref development
gh run list --workflow checks.yml --limit 5

Identificá el tercer RUN_ID. Relacioná su rama y SHA con la corrección publicada, y consultá:

gh run view RUN_ID --json status,conclusion
gh run view RUN_ID --web

Seguí los steps en el navegador, sin gh run watch. El resultado esperado es completed y success con instalación, Biome y TypeScript completos sobre el SHA corregido. Si queda en cola, verificá escucha y etiquetas. Si falla, leé el primer step fallido; no des por aprobada una corrección sólo porque la página se ve bien.

Compará las tres ejecuciones por ID y SHA, no sólo por su posición en la lista:

Ver la página y pasar el chequeo de tipos son observaciones distintas. Cuando lleves esta práctica a tu proyecto, usá tu linter, typecheck o tests habituales. Antes de automatizar sobre PR y admitir código de terceros, diseñá el aislamiento del runner y sus permisos. Esta práctica manual y efímera no es una configuración de producción.

Para cerrar, esperá a que termine el runner. exec hace salir su container tras el único job. Comprobalo desde el host:

docker ps

No debe quedar lab-runner ejecutando trabajos. GitHub tampoco debe mostrar ese runner efímero disponible para otro job. No detengas recursos ajenos. Si el job ya terminó pero una instancia de esta práctica sigue activa, revisá su terminal y detené sólo esa instancia antes de dar acceso al agente.

No sigas al agente si no tenés las tres evidencias con sus SHA correctos, el tercer run no pasó o queda un runner de este ejercicio activo.