Barrí 50 repositorios: dos defectos reales y una tasa del 2 %

0 · Veredicto en una línea De 50 repositorios de empresa con CI (≥ 5 000 ★, IA/DevTools/Fintech), 1 tiene hoy un defecto de señal de CI que yo firmaría con mi nombre en su repo; los otros dos blancos tienen defecto real pero condición distinta, y aquí se dice cuál es cuál en vez de vender los tres igual. 1 · La medición — el denominador, antes de la conclusión qué se midió magnitud cómo se obtuvo cohorte 50 repos 273 candidatos de 12 búsquedas gh search repos → filtro de listas awesome/cursos/clones y > 900 MB archivos de workflow leídos 765 descarga de .github/workflows/* por API, parseo con PyYAML pasos que invocan un runner de tests 262 regex de runners (pytest, ctest, go test, npm test, tox, make test, dotnet test, bazel test, …) pasos cuya caída no puede propagarse al resultado del workflow 11 · 4,2 % continue-on-error (paso o job) o `\ repos distintos con al menos uno 5 · 10 % {% raw %}livekit/agents, ggml-org/llama.cpp, PrefectHQ/prefect, raga-ai-hub/RagaAI-Catalyst, Arize-ai/phoenix de esos 5, con declaración explícita de intención 3 Prefect se llama (advisory) y lo comenta (api-compatibility-tests.yaml:19-21); llama.cpp deja el gate real en e2e-tests; Arize es un workflow de bot (claude-daily-deps-upgrade.yml) de los 2 restantes, repo vivo 1 livekit/agents publica commits hoy (2026-11-06); RagaAI-Catalyst no tiene commit desde 2025-05-16 ⇒ Tasa de blancos defendibles: 1/50 = 2 %. Para tres blancos vivos haría falta barrer ~150 repos. 1.1 · Auto-auditoría del instrumento (tres correcciones medidas en este turno) El primer clasificador era ciego a los gates por needs:. La v1 sólo miraba pasos posteriores dentro del mismo job. La v2 añadió consumidores needs: y guardas needs.X.result → mismo resultado (10 vs 10). El número sobrevivió, pero el argumento no estaba probado hasta que se probó. La regex de runners era corta. No veía make test, dotnet test, bazel test, phpunit, rspec. Ampliada: 262 pasos, +1 repo (Arize-ai/phoenix, workflow de bot). La tasa se movió de 4/50 a 5/50 y la de blancos defendibles no se movió. El ranking de «dolor de CI» del rastreo estaba contaminado y se descarta. Contaba corridas de ramas de fork y action_required (workflow que nunca llegó a ejecutarse) como fallos. Medido en openai/evals: 11 de 15 corridas recientes son action_required — de ahí el 0.99 de la primera pasada. Un repo con CI sana puede producir esa cifra. El ranking se retira; no se usa en ninguna decisión de este documento. 2 · Los tres blancos # repo ★ pin medido defecto locus severidad repo vivo 1 livekit/agents 15 107 055744e1505b la suite STT no puede fallar (doble capa) test-stt.yml:201 MEDIA sí (commit hoy) 2 raga-ai-hub/RagaAI-Catalyst 16 185 ab6789331089 el pipeline entero es asesorativo + salida muerta ci.yml:12,41,93 ALTA no (último commit 2025-05-16) 3 ggml-org/llama.cpp 133 519 4b77dee0524c unit/client tests asesorativos mientras E2E sí gatea ui.yml:55 · build-sanitize.yml:40 BAJA sí (commit hoy) El blanco de mayor severidad está en el repo más muerto. n=2 no permite afirmar correlación: se publica como observación, no como ley. 3 · Blanco 1 — livekit/agents (el único que firmo) El defecto, verbatim en test-stt.yml@055744e1505b:201 - name: Run STT tests run: | uv run pytest -n 3 -v --stt --tb=long --junitxml=test-results.xml 2>&1 | tee test-output.txt || true Dos capas independientes borran el resultado: || true convierte cualquier salida distinta de cero en 0. Aunque se quite || true, la tubería termina en tee, y en el bash por defecto (sin pipefail) el estado del paso es el de tee, que es 0 siempre que pueda escribir el archivo. Borrar || true a secas no restaura la guarda — esto es lo que separa una lectura superficial de una medición. Por qué probablemente no es lo que se quiso Los pasos posteriores ya están escritos para correr pase lo que pase (Generate test summary y Post results to PR llevan if: always()), y pytest --junitxml escribe el XML también al fallar. El || true no es necesario para que exista el reporte: always() ya lo compraba. Lo único que compra es que una suite STT roja sea indistinguible de una verde en la lista de checks. El contraste que hace creíble el reporte El mismo repositorio ya implementa el patrón correcto en ci.yml:34-43: continue-on-error: true sobre ruff más un paso Report ruff errors con if: steps.ruff-check.outcome == 'failure' || … que hace exit 1. Es decir: la casa sabe cerrar una guarda. test-stt.yml es una inconsistencia, no una filosofía. Texto del Issue — listo para pegar Título: ci: Test STT reports green on a failing suite — || trueplus ateepipeline erase the exit code Body: What .github/workflows/test-stt.yml:201 cannot fail: - name: Run STT tests run: | uv run pytest -n 3 -v --stt --tb=long --junitxml=test-results.xml 2>&1 | tee test-output.txt || true Two independent layers erase the result: || true turns any non-zero exit into 0. Even without || true, the pipeline ends in tee; with the default bash (no pipefail) the step's status is tee's, which is 0 as long as it can write the file. So deleting || true alone does not restore the gate. Measured at livekit/agents@055744e1505b1489976d06ca029b3001bc91ea55. Why it is probably not what you meant The steps after it already run regardless of the test outcome (Generate test summary and Post results to PR both carry if: always()), and pytest --junitxml writes the XML on failure too. The || true is not needed for the report to exist — always() already buys that. What it buys is that a red STT suite looks exactly like a green one in the checks list. Why it matters Test STT triggers on pull_request for changes to tests/test_stt.py and to its own workflow — the PRs most likely to break STT. The PR comment lists per-provider results, but nothing in the merge UI does. If this workflow is advisory by design, its name and a comment should say so; if it is a gate, it does not gate. Reproduction git clone --depth 1 https://github.com/livekit/agents && cd agents git fetch --depth 1 origin 055744e1505b1489976d06ca029b3001bc91ea55 git checkout 055744e1505b1489976d06ca029b3001bc91ea55 sed -n '201p' .github/workflows/test-stt.yml bash -c 'false | tee out.txt || true'; echo "exit=$?" # 0