---
read_when:
    - Necesitas entender por qué un trabajo de CI se ejecutó o no se ejecutó
    - Estás depurando comprobaciones fallidas de GitHub Actions
summary: Grafo de trabajos de CI, compuertas por alcance y equivalentes de comandos locales
title: Canalización de CI
x-i18n:
    generated_at: "2026-04-26T11:24:44Z"
    model: gpt-5.4
    provider: openai
    source_hash: 1a6c14f785434585f2b3a72bcd2cff3a281e51fe12cc4c14aa7613d47cd8efc4
    source_path: ci.md
    workflow: 15
---

La CI se ejecuta en cada push a `main` y en cada pull request. Usa un alcance inteligente para omitir trabajos costosos cuando solo cambiaron áreas no relacionadas.

QA Lab tiene carriles de CI dedicados fuera del workflow principal con alcance inteligente. El workflow `Parity gate` se ejecuta en cambios coincidentes de PR y en ejecución manual; compila el runtime privado de QA y compara los paquetes agénticos simulados de GPT-5.5 y Opus 4.6. El workflow `QA-Lab - All Lanes` se ejecuta cada noche en `main` y en ejecución manual; distribuye en paralelo el parity gate simulado, el carril Matrix en vivo y el carril Telegram en vivo. Los trabajos en vivo usan el entorno `qa-live-shared`, y el carril de Telegram usa concesiones de Convex. `OpenClaw Release Checks` también ejecuta los mismos carriles de QA Lab antes de aprobar la versión.

El workflow `Duplicate PRs After Merge` es un workflow manual de mantenimiento para limpiar PR duplicados después del merge. Usa `dry-run` de forma predeterminada y solo cierra los PR indicados explícitamente cuando `apply=true`. Antes de modificar GitHub, verifica que el PR integrado esté fusionado y que cada duplicado tenga o bien un issue referenciado compartido o bien fragmentos modificados superpuestos.

El workflow `Docs Agent` es un carril de mantenimiento de Codex orientado por eventos para mantener la documentación existente alineada con los cambios integrados recientemente. No tiene una programación pura: una ejecución de CI correcta en `main` tras un push no realizado por bots puede activarlo, y la ejecución manual puede ejecutarlo directamente. Las invocaciones por ejecución de workflow se omiten cuando `main` ya avanzó o cuando se creó otra ejecución de Docs Agent no omitida en la última hora. Cuando se ejecuta, revisa el rango de commits desde el SHA de origen del anterior Docs Agent no omitido hasta el `main` actual, por lo que una ejecución por hora puede cubrir todos los cambios acumulados en main desde la última pasada de documentación.

El workflow `Test Performance Agent` es un carril de mantenimiento de Codex orientado por eventos para pruebas lentas. No tiene una programación pura: una ejecución de CI correcta en `main` tras un push no realizado por bots puede activarlo, pero se omite si otra invocación por ejecución de workflow ya se ejecutó o está ejecutándose ese día UTC. La ejecución manual omite esa compuerta diaria de actividad. El carril compila un informe de rendimiento de Vitest de la suite completa agrupado, permite que Codex haga solo pequeñas correcciones de rendimiento de pruebas que preserven la cobertura en lugar de refactorizaciones amplias, luego vuelve a ejecutar el informe de la suite completa y rechaza cambios que reduzcan el número base de pruebas aprobadas. Si la línea base tiene pruebas fallidas, Codex solo puede corregir fallos evidentes y el informe de la suite completa posterior al agente debe aprobarse antes de que se confirme nada. Cuando `main` avanza antes de que llegue el push del bot, el carril hace rebase del parche validado, vuelve a ejecutar `pnpm check:changed` y reintenta el push; los parches obsoletos con conflictos se omiten. Usa Ubuntu alojado por GitHub para que la acción de Codex pueda mantener la misma postura de seguridad sin sudo que el agente de documentación.

```bash
gh workflow run duplicate-after-merge.yml \
  -f landed_pr=70532 \
  -f duplicate_prs='70530,70592' \
  -f apply=true
```

## Descripción general de los trabajos

| Trabajo                          | Propósito                                                                                    | Cuándo se ejecuta                    |
| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ |
| `preflight`                      | Detectar cambios solo de documentación, alcances modificados, extensiones modificadas y compilar el manifiesto de CI | Siempre en pushes y PR no borrador   |
| `security-scm-fast`              | Detección de claves privadas y auditoría de workflows mediante `zizmor`                      | Siempre en pushes y PR no borrador   |
| `security-dependency-audit`      | Auditoría del lockfile de producción sin dependencias frente a avisos de npm                 | Siempre en pushes y PR no borrador   |
| `security-fast`                  | Agregado requerido para los trabajos rápidos de seguridad                                    | Siempre en pushes y PR no borrador   |
| `build-artifacts`                | Compilar `dist/`, Control UI, comprobaciones de artefactos compilados y artefactos reutilizables posteriores | Cambios relevantes para Node         |
| `checks-fast-core`               | Carriles rápidos de corrección en Linux como comprobaciones de paquetes incluidos/contrato de Plugin/protocolo | Cambios relevantes para Node         |
| `checks-fast-contracts-channels` | Comprobaciones fragmentadas de contratos de canal con un resultado agregado estable          | Cambios relevantes para Node         |
| `checks-node-extensions`         | Fragmentos completos de pruebas de Plugins incluidos en toda la suite de extensiones         | Cambios relevantes para Node         |
| `checks-node-core-test`          | Fragmentos de pruebas principales de Node, excluyendo canales, paquetes incluidos, contratos y carriles de extensiones | Cambios relevantes para Node         |
| `extension-fast`                 | Pruebas centradas solo en los Plugins incluidos modificados                                  | Pull requests con cambios de extensiones |
| `check`                          | Equivalente local principal fragmentado: tipos prod, lint, guardas, tipos de prueba y smoke estricto | Cambios relevantes para Node         |
| `check-additional`               | Fragmentos de arquitectura, límites, guardas de superficie de extensiones, límites de paquetes y gateway-watch | Cambios relevantes para Node         |
| `build-smoke`                    | Pruebas smoke de CLI compilada y smoke de memoria al inicio                                  | Cambios relevantes para Node         |
| `checks`                         | Verificador para pruebas de canales con artefactos compilados más compatibilidad Node 22 solo en push | Cambios relevantes para Node         |
| `check-docs`                     | Formato de documentación, lint y comprobaciones de enlaces rotos                             | Cambios en documentación             |
| `skills-python`                  | Ruff + pytest para Skills con backend Python                                                 | Cambios relevantes para Skills Python |
| `checks-windows`                 | Carriles de prueba específicos de Windows                                                    | Cambios relevantes para Windows      |
| `macos-node`                     | Carril de pruebas TypeScript en macOS usando los artefactos compilados compartidos           | Cambios relevantes para macOS        |
| `macos-swift`                    | Lint, compilación y pruebas de Swift para la app de macOS                                    | Cambios relevantes para macOS        |
| `android`                        | Pruebas unitarias de Android para ambas variantes más una compilación debug de APK           | Cambios relevantes para Android      |
| `test-performance-agent`         | Optimización diaria de pruebas lentas con Codex tras actividad de confianza                  | Éxito de CI en main o ejecución manual |

## Orden de fallo rápido

Los trabajos están ordenados para que las comprobaciones baratas fallen antes de que se ejecuten las costosas:

1. `preflight` decide qué carriles existen en absoluto. La lógica `docs-scope` y `changed-scope` son pasos dentro de este trabajo, no trabajos independientes.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` y `skills-python` fallan rápido sin esperar a los trabajos más pesados de artefactos y matrices de plataforma.
3. `build-artifacts` se solapa con los carriles rápidos de Linux para que los consumidores posteriores puedan empezar en cuanto la compilación compartida esté lista.
4. Después se distribuyen los carriles más pesados de plataforma y runtime: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` solo para PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` y `android`.

La lógica de alcance vive en `scripts/ci-changed-scope.mjs` y está cubierta por pruebas unitarias en `src/scripts/ci-changed-scope.test.ts`.
Las ediciones del workflow de CI validan el grafo de CI de Node más el lint de workflows, pero no fuerzan por sí solas compilaciones nativas de Windows, Android o macOS; esos carriles de plataforma siguen limitados a cambios en el código fuente de la plataforma.
Las ediciones solo de enrutamiento de CI, determinadas ediciones baratas de fixtures de pruebas del núcleo y ediciones limitadas de auxiliares de contratos de Plugin/pruebas de enrutamiento usan una ruta rápida de manifiesto solo para Node: preflight, seguridad y una sola tarea `checks-fast-core`. Esa ruta evita artefactos de compilación, compatibilidad con Node 22, contratos de canal, fragmentos completos del núcleo, fragmentos de Plugins incluidos y matrices de guardas adicionales cuando los archivos modificados se limitan a las superficies de enrutamiento o auxiliares que la tarea rápida ejercita directamente.
Las comprobaciones de Node para Windows se limitan a envoltorios de procesos/rutas específicos de Windows, auxiliares de ejecución de npm/pnpm/UI, configuración del gestor de paquetes y las superficies del workflow de CI que ejecutan ese carril; los cambios no relacionados de código fuente, Plugins, install-smoke y solo pruebas permanecen en los carriles Linux de Node para que no reserven un worker de Windows de 16 vCPU para una cobertura que ya ejercitan los fragmentos normales de pruebas.
El workflow separado `install-smoke` reutiliza el mismo script de alcance a través de su propio trabajo `preflight`. Divide la cobertura smoke en `run_fast_install_smoke` y `run_full_install_smoke`. Los pull requests ejecutan la ruta rápida para superficies de Docker/paquetes, cambios de paquete/manifiesto de Plugins incluidos y superficies centrales de Plugin/canal/Gateway/Plugin SDK que ejercitan los trabajos smoke de Docker. Los cambios solo de código fuente en Plugins incluidos, las ediciones solo de pruebas y las ediciones solo de documentación no reservan workers de Docker. La ruta rápida compila una vez la imagen del Dockerfile raíz, comprueba la CLI, ejecuta el smoke de CLI `agents delete shared-workspace`, ejecuta el e2e `container gateway-network`, verifica un argumento de compilación de extensión incluida y ejecuta el perfil de Docker acotado de Plugin incluido bajo un tiempo de espera agregado de comando de 240 segundos, con el `docker run` de cada escenario limitado por separado. La ruta completa mantiene la cobertura de instalación de paquetes QR y de Docker/actualización del instalador para ejecuciones programadas nocturnas, ejecuciones manuales, comprobaciones de versión por workflow-call y pull requests que realmente tocan superficies de instalador/paquete/Docker. Los pushes a `main`, incluidos los commits de merge, no fuerzan la ruta completa; cuando la lógica de changed-scope solicitaría cobertura completa en un push, el workflow mantiene el smoke rápido de Docker y deja el install smoke completo para la validación nocturna o de versión. El smoke lento del proveedor de imágenes con instalación global de Bun está protegido por separado mediante `run_bun_global_install_smoke`; se ejecuta en la programación nocturna y desde el workflow de comprobaciones de versión, y los despachos manuales de `install-smoke` pueden activarlo, pero los pull requests y los pushes a `main` no lo ejecutan. Las pruebas QR y de Docker del instalador mantienen sus propios Dockerfiles centrados en instalación. El `test:docker:all` local precompila una imagen compartida de pruebas en vivo y una imagen de aplicación compilada compartida de `scripts/e2e/Dockerfile`, y luego ejecuta los carriles smoke live/E2E con un planificador ponderado y `OPENCLAW_SKIP_DOCKER_BUILD=1`; ajusta el número predeterminado de slots del grupo principal de 10 con `OPENCLAW_DOCKER_ALL_PARALLELISM` y el número de slots del grupo final sensible al proveedor de 10 con `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Los límites de carriles pesados usan por defecto `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` y `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7` para que las instalaciones npm y los carriles multiservicio no sobrecarguen Docker mientras los carriles más ligeros siguen llenando los slots disponibles. El inicio de carriles se escalona 2 segundos por defecto para evitar tormentas de creación en el daemon local de Docker; puedes cambiarlo con `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` u otro valor en milisegundos. El agregado local comprueba previamente Docker, elimina contenedores E2E obsoletos de OpenClaw, emite el estado de carriles activos, conserva tiempos de carriles para ordenación de más largo primero y admite `OPENCLAW_DOCKER_ALL_DRY_RUN=1` para inspeccionar el planificador. Deja de programar nuevos carriles agrupados tras el primer fallo por defecto, y cada carril tiene un tiempo de espera de reserva de 120 minutos que puede sustituirse con `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; determinados carriles live/tail usan límites por carril más estrictos. El workflow reutilizable live/E2E refleja el patrón de imagen compartida compilando y publicando una única imagen Docker E2E etiquetada con SHA en GHCR antes de la matriz Docker, y luego ejecutando la matriz con `OPENCLAW_SKIP_DOCKER_BUILD=1`. El workflow programado live/E2E ejecuta diariamente la suite Docker completa de ruta de versión. La matriz de actualización incluida se divide por destino de actualización para que las pasadas repetidas de actualización npm y reparación con doctor puedan fragmentarse junto con otras comprobaciones incluidas.

La lógica local de carriles modificados vive en `scripts/changed-lanes.mjs` y se ejecuta mediante `scripts/check-changed.mjs`. Esa compuerta local es más estricta respecto a los límites de arquitectura que el amplio alcance de plataforma de CI: los cambios de producción del núcleo ejecutan typecheck de producción del núcleo más pruebas del núcleo, los cambios solo de pruebas del núcleo ejecutan solo typecheck/pruebas del núcleo para pruebas, los cambios de producción de extensiones ejecutan typecheck de producción de extensiones más pruebas de extensiones, y los cambios solo de pruebas de extensiones ejecutan solo typecheck/pruebas de extensiones para pruebas. Los cambios públicos del SDK de Plugin o de contratos de Plugin amplían la validación a extensiones porque las extensiones dependen de esos contratos centrales. Los aumentos de versión solo de metadatos de versión ejecutan comprobaciones dirigidas de versión/configuración/dependencias raíz. Los cambios desconocidos en raíz/configuración fallan de forma segura hacia todos los carriles.

En los pushes, la matriz `checks` añade el carril exclusivo para push `compat-node22`. En los pull requests, ese carril se omite y la matriz se mantiene centrada en los carriles normales de pruebas/canales.

Las familias de pruebas de Node más lentas se dividen o equilibran para que cada trabajo siga siendo pequeño sin sobrerreservar runners: los contratos de canal se ejecutan como tres fragmentos ponderados, las pruebas de Plugins incluidos se equilibran entre seis workers de extensión, los pequeños carriles unitarios del núcleo se emparejan, auto-reply se ejecuta como cuatro workers equilibrados con el subárbol reply dividido en fragmentos de agent-runner, dispatch y commands/state-routing, y las configuraciones agénticas de gateway/Plugin se distribuyen entre los trabajos de Node agénticos existentes solo de código fuente en lugar de esperar a artefactos compilados. Las pruebas amplias de navegador, QA, medios y Plugins varios usan sus configuraciones Vitest dedicadas en lugar del comodín compartido de Plugins. Los trabajos fragmentados de extensiones ejecutan hasta dos grupos de configuración de Plugin a la vez con un worker de Vitest por grupo y un heap de Node mayor para que los lotes de Plugins con muchas importaciones no creen trabajos de CI adicionales. El amplio carril de agentes usa el planificador compartido de paralelismo por archivo de Vitest porque está dominado por importación/planificación y no por un único archivo de prueba lento. `runtime-config` se ejecuta con el fragmento infra core-runtime para evitar que el fragmento de runtime compartido sea el que se quede al final. Los fragmentos de patrones de inclusión registran entradas de tiempo usando el nombre del fragmento de CI, de modo que `.artifacts/vitest-shard-timings.json` pueda distinguir una configuración completa de un fragmento filtrado. `check-additional` mantiene juntos el trabajo de compilación/canary de límites de paquetes y separa la arquitectura de topología de runtime de la cobertura de gateway watch; el fragmento de guarda de límites ejecuta sus pequeñas guardas independientes simultáneamente dentro de un trabajo. Gateway watch, las pruebas de canal y el fragmento de límites de soporte del núcleo se ejecutan simultáneamente dentro de `build-artifacts` después de que `dist/` y `dist-runtime/` ya se hayan compilado, manteniendo sus nombres antiguos de comprobación como trabajos verificadores ligeros y evitando dos workers Blacksmith extra y una segunda cola de consumidores de artefactos.
La CI de Android ejecuta tanto `testPlayDebugUnitTest` como `testThirdPartyDebugUnitTest`, y luego compila el APK debug de Play. La variante third-party no tiene un conjunto de código fuente ni manifiesto separado; su carril de pruebas unitarias sigue compilando esa variante con los flags BuildConfig de SMS/registro de llamadas, al tiempo que evita un trabajo duplicado de empaquetado de APK debug en cada push relevante para Android.
`extension-fast` es solo para PR porque las ejecuciones de push ya ejecutan los fragmentos completos de Plugins incluidos. Esto mantiene la retroalimentación de Plugins modificados para revisiones sin reservar un worker Blacksmith extra en `main` para una cobertura ya presente en `checks-node-extensions`.

GitHub puede marcar trabajos sustituidos como `cancelled` cuando un push más reciente llega al mismo PR o ref `main`. Trátalo como ruido de CI a menos que la ejecución más reciente para la misma referencia también esté fallando. Las comprobaciones agregadas de fragmentos usan `!cancelled() && always()` para que sigan informando fallos normales de fragmentos, pero no se pongan en cola después de que todo el workflow ya haya sido sustituido.
La clave de concurrencia de CI está versionada (`CI-v7-*`) para que un zombi del lado de GitHub en un grupo de cola antiguo no pueda bloquear indefinidamente ejecuciones nuevas de main.

## Runners

| Runner                           | Trabajos                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ubuntu-24.04`                   | `preflight`, trabajos rápidos de seguridad y agregados (`security-scm-fast`, `security-dependency-audit`, `security-fast`), comprobaciones rápidas de protocolo/contrato/paquetes incluidos, comprobaciones fragmentadas de contratos de canal, fragmentos de `check` excepto lint, fragmentos y agregados de `check-additional`, verificadores agregados de pruebas de Node, comprobaciones de documentación, Skills de Python, workflow-sanity, labeler, auto-response; el preflight de install-smoke también usa Ubuntu alojado por GitHub para que la matriz de Blacksmith pueda entrar en cola antes |
| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, fragmentos de pruebas de Node en Linux, fragmentos de pruebas de Plugins incluidos, `android`                                                                                                                                                                                                                                                                                                                                          |
| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint`, que sigue siendo lo bastante sensible a CPU como para que 8 vCPU costaran más de lo que ahorraban; compilaciones Docker de install-smoke, donde el coste de tiempo en cola de 32 vCPU fue mayor que el ahorro                                                                                                                                                                                                                                         |
| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| `blacksmith-6vcpu-macos-latest`  | `macos-node` en `openclaw/openclaw`; los forks recurren a `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` en `openclaw/openclaw`; los forks recurren a `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                               |

## Equivalentes locales

```bash
pnpm changed:lanes   # inspeccionar el clasificador local de carriles modificados para origin/main...HEAD
pnpm check:changed   # compuerta local inteligente: typecheck/lint/pruebas modificados por carril de límite
pnpm check          # compuerta local rápida: tsgo de producción + lint fragmentado + guardas rápidas en paralelo
pnpm check:test-types
pnpm check:timed    # la misma compuerta con tiempos por etapa
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
pnpm test           # pruebas vitest
pnpm test:channels
pnpm test:contracts:channels
pnpm check:docs     # formato de documentación + lint + enlaces rotos
pnpm build          # compilar dist cuando importan los carriles de artefactos/ build-smoke de CI
pnpm ci:timings                               # resumir la última ejecución de CI de push a origin/main
pnpm ci:timings:recent                        # comparar ejecuciones recientes exitosas de CI en main
node scripts/ci-run-timings.mjs <run-id>      # resumir tiempo total, tiempo en cola y trabajos más lentos
node scripts/ci-run-timings.mjs --latest-main # ignorar ruido de issues/comentarios y elegir la CI de push a origin/main
node scripts/ci-run-timings.mjs --recent 10   # comparar ejecuciones recientes exitosas de CI en main
pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json
pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
```

## Relacionado

- [Resumen de instalación](/es/install)
- [Canales de desarrollo](/es/install/development-channels)
