Leer workflow, job y steps

Volvé al editor del host, en lab y en la rama development. Con la imagen ya explorada y tu repositorio propio publicado, vamos a leer el trabajo que recibirá el runner.

Abrí docs/snippets/checks.yml. Viajó con la app y ya no está en hackerspace-site/ dentro del checkout del material. Leé el archivo completo antes de activarlo en .github/workflows/.

Para seguir el archivo y después reconocer su resultado en GitHub, distingamos estas partes de Actions:

Parte	Qué significa acá
Workflow	Archivo YAML que define cuándo ejecutar trabajo y qué jobs contiene
Ejecución o run	Una vez que se inicia ese workflow, con un ID y un commit concretos
Job	Conjunto de pasos que se ejecuta en un runner; acá se llama `check`
Step	Un paso del job, como descargar el código o ejecutar `pnpm typecheck`
Runner	Programa que recibe el job y ejecuta sus steps en su entorno
Check	Resultado que GitHub muestra para ese trabajo sobre un commit

CI significa integración continua. Consiste en ejecutar comprobaciones repetibles sobre cambios de código para detectar fallas antes de integrarlos. Acá vamos a practicarlas con inicio manual. Tené presente que publicar un commit, iniciar el workflow y obtener un resultado son acciones distintas.

Workflow contiene un job que selecciona runner y ejecuta checkout, instalación, lint y typecheck

Diagrama del taller; ejemplo conceptual.

La primera parte dice:

name: Checks del workshop
on:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  check:
    runs-on: [self-hosted, linux, workshop]
    timeout-minutes: 10

Fijate en workflow_dispatch, que permite el inicio manual. No hay un trigger push, así que enviar un commit no ejecutará este workflow. La etiqueta workshop debe coincidir con la del runner. contents: read limita la credencial del job y el timeout limita su duración.

Dentro del mismo job:

    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
        with:
          persist-credentials: false
      - run: pnpm install --frozen-lockfile
      - run: pnpm lint
      - run: pnpm typecheck

El primer step, checkout, descarga en el runner el código de la versión que vas a comprobar. Está fijado a un commit de la acción y no conserva su credencial en Git. Después la instalación respeta el lockfile, Biome revisa reglas de código y TypeScript comprueba tipos sin necesitar abrir la página en un navegador.

Leelos en ese orden, porque así se ejecutan. Si un step falla, los siguientes de este archivo no se ejecutan y el job queda fallido. Cuando veas un check verde, recordá qué comprobó este archivo. Este workflow no ejecuta tests ni hace un deployment.

Comprobá en el archivo real el evento, las etiquetas y los cuatro steps. No sigas si el contenido no coincide o apunta a otro runner.