mapa: haz clic en un capítulo para saltar

Cinco capítulos más, del archivo al sistema

La Parte I te enseñó a leer un workflow. Esta parte explica por qué están escritos así, qué producen y cómo encajan con el resto del equipo.

El veredicto GO / CAUTION / NO-GO y la clasificación de fallos (REGRESSION vs FLAKY vs ENVIRONMENT) no se repiten aquí: viven en regression-testing/how-it-works.es.html, que arranca justo donde este deck termina.

una tabla que vale por el capítulo

Cada workflow contesta una pregunta y gatea una decisión

La secuencia clásica de la industria es smoke → sanity → regression como gates sucesivos: si smoke falla, no gastás la regresión. En este repo los gates son temporales (cron) y manuales; conectarlos al deploy de la app es el Capítulo 9.

suite 0: no prueba la app, prueba el repo de pruebas

build.yml: el gate del Pull Request

      - name: Validate env schema (varlock)
        uses: dmno-dev/varlock-action@v1.0.5
        with:
          fail-on-error: true
          show-summary: true
        # First gate, before any dependency is installed: loads .env.schema +
        # .env.core.schema against the job's env block above and writes a
        # REDACTED summary to the job page. The only required item is TEST_ENV
        # (it has a default); project credentials are optional typed examples,
        # so a PR from a fork, which has no secrets, passes here and at
        # test:env:check below. …
      # … Setup Bun · Install Dependencies
      - name: Validate Test Environment Variables
        run: bun run test:env:check
      - name: TypeScript Check
        run: bun run types:check
      - name: ESLint Check
        run: bun run lint:check
      - name: Docs Gates
        run: |
          bun run docs:check
          bun run skills:check
      - name: Documentation Contracts
        run: bun scripts/lint-doc-contracts.ts --base "$BASE_SHA" --head "$HEAD_SHA"
      - name: Skill Activation Evals Check
        run: bun run skills:evals
      - name: Playwright Compile Check
        run: bunx playwright test --list

suite 1: la pregunta más barata, la más frecuente

smoke.yml: la app está viva?

# smoke.yml
      - name: Run Smoke Tests (@critical) on ${{ env.TEST_ENV }}
        run: bun run test:smoke

# package.json
"test:smoke": "… playwright test --project=smoke-ui --project=smoke-api"

# playwright.config.ts (comentario del bloque smoke, resumido)
# Smoke Tests - @critical tagged tests, ONE PROJECT PER SURFACE
# smoke-ui  == e2e + @critical
# smoke-api == integration + @critical
{ name: 'smoke-ui',  grep: /@critical/, … }
{ name: 'smoke-api', grep: /@critical/, … }

suite 2: la única que siempre necesita que le digas qué

sanity.yml: funciona ESTE cambio?

      - name: Run Sanity Tests on ${{ env.TEST_ENV }}
        shell: bash
        env:
          GREP_INPUT: ${{ github.event.inputs.grep }}
          TEST_FILE: ${{ github.event.inputs.test_file }}
          TEST_TYPE: ${{ github.event.inputs.test_type }}
        run: |
          grep_args=()
          if [ -n "$GREP_INPUT" ]; then
            grep_args=(--grep "$GREP_INPUT")
          fi
          # Determine which test command to run
          if [ -n "$TEST_FILE" ]; then
            echo "Running specific test file: $TEST_FILE"
            bun run test "$TEST_FILE" "${grep_args[@]}"
          elif [ "$TEST_TYPE" == "e2e" ]; then
            echo "Running E2E tests"
            bun run test:e2e "${grep_args[@]}"
          elif [ "$TEST_TYPE" == "integration" ]; then
            echo "Running Integration tests"
            bun run test:integration "${grep_args[@]}"
          else
            echo "Running all tests"
            bun run test "${grep_args[@]}"
          fi

decisor: elige la situación y mira qué suite corresponde

Qué suite corro? La situación decide

quiz 06: estrategia

Qué suite y por qué?

simulador: la misma animación de la Parte I, ahora con el porqué de cada job

Cuatro jobs: dos que prueban, dos que cuentan

un reporte por run, no uno por job

Merge: dos artifacts entran, un reporte sale

      - name: Download Integration Allure Results
        uses: actions/download-artifact@v4
        with:
          name: integration-allure-results
          path: regression-artifacts/integration-allure-results
        continue-on-error: true
      - name: Download E2E Allure Results
…        (idéntico, e2e-allure-results)
      - name: Merge Allure Results
        id: merge_results
        run: |
          mkdir -p merged-allure-results
          if [ -d "regression-artifacts/integration-allure-results" ] && [ -n "$(ls -A …)" ]; then
            cp -r regression-artifacts/integration-allure-results/. merged-allure-results/
…          (lo mismo para e2e)
      - name: Check Allure Results
        id: check_allure
            echo "has_results=true" >> $GITHUB_OUTPUT
      - name: Upload Merged Allure Results
        if: steps.check_allure.outputs.has_results == 'true'
          name: merged-allure-results-${{ env.TEST_ENV }}

del artifact a una URL con historia

Publicar: gh-pages, tendencias y la URL predecible

      - name: Get Allure History
        uses: actions/checkout@v4
        with:
          ref: gh-pages                 # la rama publicada, no main
          path: gh-pages
          fetch-depth: 1
        continue-on-error: true        # primer run: la rama no existe
      - name: Build & Publish Allure Report (Allure 3)
        if: steps.check_allure.outputs.has_results == 'true'
        env:
          PORTAL_URL: ${{ secrets.PORTAL_URL }}   # + PORTAL_*, R2_* (modo privado)
        run: |
          if [ -n "$PORTAL_URL" ]; then
            bun scripts/ci/publish-allure-portal.ts …      # portal privado (R2)
          else
            bun scripts/ci/publish-allure-pages.ts \
              --env "${{ env.TEST_ENV }}" --suite regression \
              --run "${{ github.run_number }}" \
              --results merged-allure-results --pages gh-pages --keep 10
            echo "## Allure Report" >> $GITHUB_STEP_SUMMARY
            echo "View the report: https://${{ github.repository_owner }}.github.io/${{ … }}/${{ env.TEST_ENV }}/regression/" >> $GITHUB_STEP_SUMMARY
          fi

{env}/{suite}/
  index.html      → redirect relativo al último run
  history.jsonl   → tendencia Allure 3 (restaurada antes de
                    generar, guardada después)
  {runNumber}/    → un reporte completo por run
                    (se conservan los últimos 10, --keep 10)

línea de tiempo: pulsa ▶

Una noche de regresión, de 00:00 a 00:35

quiz 07: regression.yml

Leíste el archivo o solo el deck?

el mapa de los resultados

Terminó el run. Dónde miro qué?

un RTR por veredicto

Write-back: el run record nace antes que el run

simulador: mueve los tres interruptores y mira qué steps corren de verdad

La matriz: AUTO_SYNC × TMS_PROVIDER × execution_key

quiz 08: resultados y write-back

Adónde fueron los resultados?

el problema y las tres formas de resolverlo

De «corre a las 00:00» a «corre cuando la app se despliega»

Regla de las docs que hace posible todo esto: los eventos provocados con GITHUB_TOKEN no disparan otros workflows (anti-bucle) salvo workflow_dispatch y repository_dispatch. Por eso el segundo existe.

diseñador: elige mecanismo, suite y dureza del gate

Diseña el gate: los dos lados del YAML

cómo se vería el pipeline completo, con la recomendación

El pipeline objetivo: deploy → suites → producción con permiso

quiz 09: integración con el pipeline de desarrollo

Qué mecanismo elegís?

constructor: cada interruptor añade o quita un bloque; el YAML sigue el esqueleto del repo

Arma tu suite con la plantilla

checklist: marca cada punto; se guarda en este navegador

Doce controles antes de abrir el PR

• Propósito en la cabecera. Un comentario que dice qué pregunta contesta y cuándo corre. Si no podés escribirlo, no sabés qué suite es.
• Comandos de package.json, no inventados. bun run test:smoke, nunca npx playwright test … escrito a mano (Rule #11).
• Cada input tiene fallback || 'default' donde un cron pueda dispararlo.
• Ningún secret en el YAML. Solo ${{ secrets.X }}. Los nombres siguen el prefijo de entorno: STAGING_USER_EMAIL.
• Ningún input interpolado dentro de run:. Pasalo por env: y leelo como "$VAR" (docs: secure-use).
• timeout-minutes en cada job. Sin él, un cuelgue factura hasta 6 horas.
• if: always() en cada upload de resultados y failure() en la evidencia extra.
• Nombres de artifact únicos por run, con prefijo de suite/job. v4 es inmutable.
• concurrency decidida: publica → cancel-in-progress: false; solo valida → true.
• permissions mínimos si el workflow escribe en GitHub; nada declarado si solo lee.
• Acciones con versión fijada (@v4) y, para terceros críticos, SHA completo con comentario de versión.
• Probado con workflow_dispatch antes de confiar en el cron. Un cron nuevo no corre hasta estar en main; el botón sí (gh workflow run <file> --ref <tu-rama> una vez que el archivo también exista en main).

Cierre del ciclo: el PR dispara build.yml, que valida el repo pero no el YAML nuevo. El YAML lo valida bun run format:check en local (prettier) y, en última instancia, el primer run. Por eso el punto 12 no es opcional.

quiz 10: el tuyo

Último control del mini-curso

cierre: el mapa completo y qué sigue

De un archivo YAML a un sistema de calidad que corre solo

Un pipeline de testing no es una lista de comandos: es la respuesta escrita a «qué queremos saber, cuándo, y qué pasa si la respuesta es no?». Ahora sabés escribirla.

← Parte I · Fundamentos