openclaw-ci-limits

Límites de CI de OpenClaw

Usa esta habilidad para cambios de capacidad de CI, no para el triaje ordinario de fallos de pruebas. El objetivo es mantener OpenClaw rápido, distinguiendo entre registro de ejecutores, disponibilidad de ejecutores, salud del plano de control de Blacksmith y drenajes de colas posteriores.

Hechos Fundamentales

• La CI completa del nivel principal se ejecuta cada hora; los pushes ordinarios a main ejecutan security-fast. Un push verde no es evidencia de que el conjunto completo haya pasado. Los PRs ordinarios difieren Windows, macOS Node/Swift, compilación/simulador de iOS, UI de real-Gateway, actualización de driver publicado, Knip y la mayoría de las pruebas de arquitectura. Los guards de import-cycle y Kysely siguen siendo bloqueantes. Usa docs/ci/scope-and-routing/selection.md y el manifiesto actual para la selección exacta de evento, propietario y fallback de lanzamiento; no restaures carriles diferidos mientras ajustas la capacidad. Las capturas de pantalla de Android siguen siendo solo de lanzamiento.
• No asumas cuál es el recurso escaso. Demuestra si la presión proviene de registros de ejecutores, disponibilidad de ejecutores elegibles, capacidad/plano de control de Blacksmith, dependencias del flujo de trabajo, tiempo de ejecución de pruebas o un escritor de cola posterior.
• Los registros de ejecutores de GitHub para openclaw actualmente reportan un bucket de 10,000 por cada 5 minutos en actions_runner_registration. Verifica el bucket activo antes de cada pase de ajuste porque GitHub puede cambiarlo. La organización openclaw comparte un bucket.
• La cuota REST principal no consume este bucket. Verifica actions_runner_registration por separado; la cuota principal puede estar saludable mientras el registro de ejecutores está limitado.
• Usa aproximadamente el 60% del bucket activo como objetivo operativo. Con el bucket actual de 10,000 registros, mantén la carga de ráfaga planificada de Blacksmith por debajo de 6,000 registros cada 5 minutos y deja el resto para otros repositorios, reintentos y superposición de ráfagas.
• Los trabajos que enrutan, notifican, resumen, eligen fragmentos o ejecutan escaneos cortos de calidad de CodeQL deben permanecer en ejecutores alojados por GitHub a menos que la evidencia medida indique que Blacksmith es necesario.

Política de Costo de Ejecutores

• Usa el ejecutor más pequeño que complete la carga de trabajo requerida de manera confiable. Mantén los trabajos de control cortos alojados y las pruebas ordinarias de desarrollo confiable locales.
• Trata los ejecutores físicos de 8 vCPU y más grandes como excepciones, no como un valor predeterminado o reintento genérico. Registra el comando y el pico de memoria medido, un OOM en un ejecutor más pequeño, o una comparación controlada que muestre un costo total facturado menor. El uso bajo de CPU por sí solo no demuestra que un trabajo con uso intensivo de memoria pueda trasladarse a un ejecutor más pequeño. Preserva los límites de trabajador basados en recursos.
• Las Cajas de Prueba rutinarias de OpenClaw usan la clase 4 con un valor predeterminado de 60 minutos de trabajo total, incluyendo la hidratación. Mantén el techo de inactividad de 15 minutos. Plazos más cortos son bienvenidos para comandos cortos conocidos; no solicites cuatro horas automáticamente ni aumentes el tamaño solo para obtener más tiempo. Selecciona .github/workflows/ci-check-high-memory-testbox.yml explícitamente solo para un comando con nombre que use mucha memoria; consulta docs/reference/test/remote-proof.md. Ese flujo de trabajo tiene como máximo cuatro leases concurrentes dentro del grupo compartido de 32 slots de Testbox. El perfil de alta memoria usa 8 vCPUs; ambos perfiles preservan su CPU física y RAM anteriores al 3 de noviembre. Todos los perfiles de Testbox limitan el tiempo de inactividad a 15 minutos.
• Asigna a través del wrapper actual de OpenClaw con el workflow ref main; la cápsula fuente preserva el checkout que se está probando. No envíes un workflow ref antiguo para eludir los límites de gasto. La antigüedad de la cola se verifica antes del checkout; un lease admitido mantiene sus plazos de trabajo e inactividad.
• No promuevas una familia completa de flujos de trabajo porque un comando necesite más RAM. Mantén las filas de CI con alto uso de memoria comprobado limitadas a su planificador propietario y evidencia; vuelve a medir antes de cambiar su asignación. Una etiqueta de clase 32 no es prueba de 32 CPUs disponibles. Compara los recursos observados y el costo total facturado del trabajo.

Experimentos Rechazados

• Checkout sparse sin blobs de UI (2026-10-16): Excluir los árboles de aplicaciones nativas móviles/macOS eliminó 48.31 MiB de contenido lógico rastreado, pero no calificó como una mejora en el costo de ejecutores. En run 38866595993, el checkout de UI E2E de Blacksmith tomó 56s y el checkout del navegador alojado 58s; los checkouts completos de UI en la misma ejecución tomaron 22–38s. Estas son muestras pequeñas y no apareadas, no un delta de facturación medido. Mantén el checkout completo de la fuente. Reconsidera solo con un tiempo de checkout completo y un costo facturado más bajos, incluyendo fetch filtrado, materialización perezosa y exportación de harness confiable; menos bytes lógicos por sí solos no establecen ahorros.
• Selección de propietario de fixture de declaración (2026-10-02): test/scripts/tsdown-declaration-fixture.ts deriva copias fuente reales de sus closures de punto de entrada en tiempo de ejecución, por lo que los PRs de producto que editan uno no seleccionan las cuatro suites de declaración construidas sobre él. PR #162614 rompió write-unified-entry-dts de esa manera; la CI programada por hora (run 36979748808) lo detectó unos 35 minutos después de la fusión y 0a188c4f038f0 reparó el fixture dentro de la hora. Declarar los propietarios como literales new URL(..., import.meta.url) alcanza las suites solo por debajo del límite de 20 importadores del hub de selección agresiva: el propietario del incidente y otros siete son hubs, por lo que el diff rehecho de #162614 aún no seleccionó ninguno. Reproduciendo los 92 commits principales de los 30 días anteriores que tocaron un propietario a través de las opciones canónicas del planificador de PRs, los literales URL cubrieron recientemente 12 (+35 filas, +1,689 class-vCPU-minutos). La cobertura completa, como una política de vigilancia sobre la misma lista, selecciona recientemente las suites para 81 e inicia build-artifacts (mediana de 330s en la clase 16 en 12 ejecuciones de PR) para 69, porque las suites son propietarios de compilación en ci-build-manifest.mjs: +242 filas y +11,628 class-vCPU-minutos, una mediana de +161 (+8%) por PR afectado. Eso compra una rotura de propietario escapada en siete semanas, así que mantén las rutas simples; la CI programada por hora, los PRs de propietarios de herramientas y la validación de lanzamiento son dueños de esta prueba. Reconsidera solo con una tasa de escape materialmente más alta o una selección que no inicie también build-artifacts.
• Preparación de entrada asíncrona de límite (2026-09-26): Agregar las llamadas existentes CompilerInputSnapshot.prepare() en los tres llamadores de declaración/límite aumentó la validación completa en frío de 464.21s a 544.68s en la misma Testbox de cuatro CPU/15.42 GiB; la validación en caliente aumentó de 12.62s a 14.63s. Las 125 verificaciones de plugins y la canary pasaron, pero el uso de CPU también aumentó. Se eliminaron las seis adiciones de llamadores. No repitas esto como una aceleración asumida; cualquier uso diferente necesita un beneficio medido de extremo a extremo.
• Almacén pnpm de Windows (2026-09-20): Los recibos originales de run 35547255790 midieron la configuración completa mediana en 45.295s en frío frente a 52.738s restaurado (+16.4%), a pesar de reutilizar los 1,453 paquetes con cero descargas. El archivo de 763.8 MiB tomó 23.601–26.980s en restaurarse; la configuración/guardado del productor agregó 62.527s. Los siete trabajos nativos pasaron, pero el reductor de calificación falló en una diferencia de RAM reportada de 24 KiB. No se relajaron afirmaciones ni se volvieron a ejecutar trabajos. El subconjunto exactamente emparejado en RAM aún era 11.3% más lento; eso es evidencia descriptiva, no un reemplazo que pase la calificación. Mantén la configuración normal de Windows sin caché. Reconsidera solo con ahorros netos de configuración completa, incluyendo restauración, extracción, reconciliación congelada y trabajo del productor.
• Dependencias exactas de Mac alojado (2026-09-01): El publicador y consumidor de la misma cabeza en run 33458856298 guardaron y restauraron con éxito un archivo de dependencias de 1.66 GB, pero la configuración tomó 142s frente a 86s con la caché de almacén ordinaria. La extracción tomó 82s frente a 27s; la instalación mejoró solo de 43s a 35s. Mantén los trabajos de Mac alojado en la caché de almacén ordinaria. Reconsidera solo con ahorros totales de configuración medidos, incluyendo transferencia, extracción y reconciliación congelada, no un acierto de caché exitoso.
• Checkout de artefacto de acciones (2026-08-16): No recomiendes reemplazar el fetch compartido de Git de Blacksmith con un espacio de trabajo producido en preflight o un artefacto .git. PR #124818 midió una línea base de checkout de Blacksmith de 16s frente a 7s alojado. La mejor variante de artefacto directo costó 1s para empaquetar, 3s para subir y 11s de mediana para restaurar; incluyendo el prefijo serial, dejó solo aproximadamente 1s de mejora mediana y regresó las ejecuciones de fetch rápido de Blacksmith. El cliente de artefacto oficial fue peor: run 31971531521 midió 22s de descarga mediana más 2s de materialización. La ruta rápida de caché de acciones de Blacksmith no implica descargas rápidas de artefactos de acciones. Reconsidera solo con prueba medida de extremo a extremo para un transporte diferente, incluyendo su costo de productor y regresiones de fetch rápido.

Primeras Verificaciones

Antes de cambiar CI, recopila la presión actual:

gh api rate_limit --jq '{core:.resources.core,graphql:.resources.graphql,search:.resources.search,actions_runner_registration:.resources.actions_runner_registration}'
gh run list -R openclaw/openclaw --limit 20 --json databaseId,status,conclusion,workflowName,event,headBranch,createdAt,updatedAt,url
gh run list -R openclaw/clawsweeper --limit 20 --json databaseId,status,conclusion,workflowName,event,headBranch,createdAt,updatedAt,url
gh api repos/openclaw/clawsweeper/actions/runs/<run-id>/jobs --paginate --jq '.jobs[] | {id,name,status,conclusion,labels,created_at,started_at,completed_at,runner_name,runner_group_name}'
blacksmith testbox list --all
curl -fsS https://clawsweeper.openclaw.ai/api/status | jq '{generated_at,fleet,diagnostics:{errors:.diagnostics.errors}}'
curl -fsS https://clawsweeper.openclaw.ai/api/exact-review-queue | jq '{generated_at,review:.lanes.review,publication:.lanes.publication,state_writer,state_append}'
node scripts/ci-run-timings.mjs --latest-main
node scripts/ci-run-timings.mjs --recent 10

Para una ejecución en cola sospechosa, inspecciona sus trabajos. Un estado queued a nivel de ejecución no revela si el trabajo está esperando dependencias o no tiene un ejecutor elegible. Compara created_at, started_at, labels y runner_name. Vuelve a verificar las ejecuciones en cola obsoletas en vivo antes de cancelarlas; cancela solo las ejecuciones que se demuestren obsoletas.

warmup de Testbox confirma la creación del lease, no la preparación del ejecutor. Una instantánea queued inicial sin providerMetadata.runURL no establece una escasez de capacidad. Usa esa URL para inspeccionar el flujo de trabajo exacto una vez asociado. Un ejecutor de verificación asignado que realiza la configuración es hidratación; una admisión confirmada o cola de capacidad sigue la política existente de asignación de propiedad detenida. No infieras asociación de la ejecución de flujo de trabajo más reciente ni esperes en una cola de capacidad confirmada.

El retraso de inicio de scripts/ci-run-timings.mjs puede incluir la espera de dependencia del flujo de trabajo más el tiempo de cola del ejecutor. Es evidencia de tendencia, no prueba de presión de ejecutor por sí sola.

Lee:

• .github/workflows/ci.yml
• .github/workflows/codeql-critical-quality.yml
• docs/ci.md
• test/scripts/ci-workflow-guards.test.ts
• test/scripts/ci-workflow-planning.test.ts
• test/scripts/ci-workflow-evidence.test.ts
• archivos de planificador tocados bajo scripts/lib/*ci*, scripts/lib/*test-plan* o scripts/ci-changed-scope.mjs

Diagnosticar el Cuello de Botella

Clasifica el problema antes de cambiar los límites:

• Limitación de registro de ejecutor: muchos trabajos en cola antes de la asignación de ejecutor, Blacksmith/GitHub reporta respuestas 403/429 o 422 de tipo spam de generate-jitconfig, y la cuota principal de la API aún está saludable. Trata 422 como esta señal solo cuando la carga útil de la solicitud sea válida. Corrige la ráfaga y el recuento de trabajos de Blacksmith.
• Capacidad de Blacksmith: el panel de Blacksmith muestra límites de concurrencia reales o capacidad no disponible. No resuelvas esto solo con la expansión del flujo de trabajo de GitHub.
• Plano de control de Testbox de Blacksmith: las llamadas list, warm, status o run agotan el tiempo de espera antes de que se devuelva un lease. Esto es independiente del registro de ejecutores de Actions y la capacidad de trabajos de Actions. La fuente confiable puede usar el fallback local documentado; la fuente no confiable permanece bloqueada.
• Etiqueta de ejecutor no disponible: un trabajo está en cola con una etiqueta runs-on personalizada, started_at y runner_name permanecen vacíos, y no existe un ejecutor elegible. Restaura una etiqueta alojada o registrada disponible; la expansión no puede solucionarlo.
• Espera de dependencia de flujo de trabajo: el trabajo está en cola pero los predecesores requeridos no son terminales. Corrige o espera la dependencia; no llames a todo el retraso presión de cola de ejecutor.
• Tiempo de ejecución de prueba de OpenClaw: los trabajos comienzan rápido pero un carril domina el tiempo de pared. Usa $openclaw-test-performance en lugar de ajuste de ejecutor.
• CI realmente fallando: un trabajo falla después de comenzar. Usa $github:gh-fix-ci o $openclaw-testing, no esta habilidad.
• Acumulación de revisión de ClawSweeper: revisión pendiente/lista crece mientras la publicación y los escritores de estado se mantienen saludables. Ajusta la admisión/trabajadores de revisión en openclaw/clawsweeper.
• Acumulación de publicación de ClawSweeper: publicación pendiente/lista y la edad más antigua crecen, el drenaje neto es cero o negativo, o las cartas muertas aumentan. Inspecciona primero los lotes de publicación, la coordinación del escritor de estado y la latencia de mutación de GitHub.
• Acumulación de materializador/append de estado: state_append.pending_rows, pending_bytes o la edad más antigua crecen mientras el materializador está en cola o ausente. Recupera ese único drenaje primero; más trabajadores de revisión lo empeoran.

Matemática del Presupuesto de Registro

Estima los registros en el peor de los casos para un cambio antes de editar:

nuevos registros de Blacksmith ~= número de trabajos de Blacksmith que pueden ponerse en cola dentro de una ventana de 5 minutos

Para trabajos de matriz, cuenta cada fila que pueda comenzar en la ventana de 5 minutos. strategy.max-parallel solo limita las filas simultáneas; las filas cortas pueden rotar y registrar más ejecutores antes de que se reinicie la ventana. Usa la duración del trabajo, los reintentos y la rotación de la cola para justificar cualquier estimación más baja. Agrega trabajos de Blacksmith que no sean de matriz como preflight, security-fast, build-artifacts y carriles de plataforma.

Para reintentos de instancia de ejecución o de movimiento descendente, duplica el recuento esperado de registros para esa instancia.

Consulta la salida de gh api rate_limit y el panel de estado de ClawSweeper antes de implementar cambios de capacidad. Mantén una reserva del 40% del bucket para otros repositorios de la organización.

Estrategias de Cambio de Capacidad

• Expansión de ejecutor Blacksmith (cambio de conjunto): ajusta blacksmith_runner_labels en el manifiesto de CI. Agrega un nuevo conjunto de ejecutores etiquetados; no migres trabajos uno por uno. Verifica primero el límite de registro activo. Para conjuntos de alta concurrencia, coordina con el equipo de infraestructura de Blacksmith.
• Reducción de ejecutor Blacksmith (eliminación de conjunto): mueve trabajos a un conjunto existente o a ejecutores alojados. Elimina la etiqueta del manifiesto; no dejes trabajos huérfanos. Monitorea la cola de registro durante 5 minutos después de la reducción.
• Cambio max-parallel de matriz: reduce max-parallel para limitar los registros de ejecutores simultáneos. Aumenta max-parallel solo con evidencia de cuota de registro suficiente y baja contención de ejecutores. Usa el tiempo de ejecución de trabajos para calibrar el límite.
• Reducción de carga de flujo de trabajo: cambia trabajos de Blacksmith a ejecutores alojados o reduce la frecuencia de los flujos de trabajo. Usa schedule o eventos push con rutas de filtro. Verifica el impacto en la cola de registro después del cambio.
• Aumento de carga de flujo de trabajo: cambia trabajos de ejecutores alojados a Blacksmith o aumenta la frecuencia. Verifica primero el límite de registro y la capacidad de Blacksmith. Implementa por etapas.

Referencia

• docs/ci/scope-and-routing/selection.md
• docs/ci/capacity-planning.md
• docs/ci/runner-cost-policy.md
• docs/reference/test/remote-proof.md
• test/scripts/ci-workflow-guards.test.ts
• test/scripts/ci-workflow-planning.test.ts
• test/scripts/ci-workflow-evidence.test.ts
• Panel de ClawSweeper: https://clawsweeper.openclaw.ai/

Después de una reducción de capacidad, monitorea durante al menos 5 minutos para que el bucket de registro se estabilice. Después de un aumento, monitorea el estado de la cola y los tiempos de inicio de trabajos. Cancela las ejecuciones obsoletas en cola después de los cambios para evitar la presión artificial de la cola.