openclaw-ci-limits

Limites de CI do OpenClaw

Use esta skill para alterações de capacidade de CI, não para triagem comum de falhas em testes. O objetivo é manter o OpenClaw rápido, distinguindo entre registro de runner, disponibilidade de runner, saúde do plano de controle do Blacksmith e drenagem de filas downstream.

Fatos Essenciais

• A CI completa do main tier é executada a cada hora; pushes comuns no main executam security-fast. Um push verde não é evidência de que o conjunto completo passou. PRs comuns adiam Windows, macOS Node/Swift, build/simulador iOS, UI real-Gateway, atualização de driver publicado, Knip e a maioria das provas de arquitetura. As proteções de ciclo de importação e Kysely permanecem bloqueantes. Use docs/ci/scope-and-routing/selection.md e o manifesto atual para seleção exata de evento, proprietário e fallback de release; não restaure faixas adiadas enquanto ajusta a capacidade. Screenshots do Android permanecem apenas para releases.
• Não assuma qual é o recurso escasso. Prove se a pressão está em registros de runner, disponibilidade de runner elegível, capacidade/plano de controle do Blacksmith, dependências de workflow, tempo de execução de teste ou um escritor de fila downstream.
• Os registros de runner do GitHub para openclaw atualmente relatam 10.000 por bucket de 5 minutos em actions_runner_registration. Verifique o bucket ativo antes de cada ajuste, pois o GitHub pode alterá-lo. A organização openclaw compartilha um bucket.
• A cota REST principal não consome este bucket. Verifique actions_runner_registration separadamente; a cota principal pode estar saudável enquanto o registro de runner está limitado.
• Use cerca de 60% do bucket ativo como alvo operacional. Com o bucket atual de 10.000 registros, mantenha a carga planejada de burst do Blacksmith abaixo de 6.000 registros a cada 5 minutos e deixe o restante para outros repositórios, tentativas e sobreposição de bursts.
• Jobs que roteiam, notificam, resumem, escolhem shards ou executam varreduras curtas de qualidade do CodeQL devem permanecer em runners hospedados pelo GitHub, a menos que evidências medidas digam que o Blacksmith é necessário.

Política de Custo de Runner

• Use o menor runner que conclua a carga de trabalho necessária de forma confiável. Mantenha jobs de controle curtos hospedados e provas de desenvolvimento confiáveis comuns locais.
• Trate runners físicos de 8 vCPUs ou maiores como exceções, não como padrão ou tentativa genérica. Registre o comando e o pico de memória medido, um OOM de runner menor ou uma comparação controlada que mostre menor custo total faturado. Baixo uso de CPU por si só não prova que um job com uso intenso de memória pode ser movido para baixo. Preserve limites de worker baseados em recursos.
• Os Testboxes de rotina do OpenClaw usam a classe 4 com um padrão de 60 minutos de job total, incluindo hidratação. Mantenha o teto de 15 minutos de inatividade. Prazos mais curtos são bem-vindos para comandos conhecidos e curtos; não solicite quatro horas automaticamente nem aumente o tamanho apenas para obter mais tempo. Selecione .github/workflows/ci-check-high-memory-testbox.yml explicitamente apenas para um comando nomeado de uso intenso de memória; veja docs/reference/test/remote-proof.md. Esse workflow tem no máximo quatro concessões simultâneas dentro do pool compartilhado de 32 slots do Testbox. O perfil de alta memória usa 8 vCPUs; ambos os perfis preservam sua CPU física e RAM anteriores a 3 de novembro. Todos os perfis de Testbox limitam o tempo ocioso a 15 minutos.
• Aloque através do wrapper atual do OpenClaw com a ref de workflow main; a cápsula de origem preserva o checkout que está sendo testado. Não despache uma ref de workflow antiga para contornar os limites de gastos. A idade da fila é verificada antes do checkout; uma concessão admitida mantém seus prazos de job e inatividade.
• Não promova uma família inteira de workflows porque um comando precisa de mais RAM. Mantenha linhas de CI de alta memória comprovadas com escopo em seu planejador proprietário e evidências; meça novamente antes de alterar sua alocação. Um rótulo de classe 32 não é prova de 32 CPUs disponíveis. Compare recursos observados e custo total do job faturado.

Experimentos Rejeitados

• Checkout esparso sem blobs de UI (2026-10-16): Excluir árvores de aplicativos nativos móveis/macOS removeu 48,31 MiB de conteúdo lógico monitorado, mas não se qualificou como uma melhoria de custo de runner. Em run 38866595993, o checkout E2E da UI do Blacksmith levou 56s e o checkout do navegador hospedado 58s; checkouts completos de UI na mesma execução levaram 22–38s. Estas são amostras pequenas e não pareadas, não um delta de faturamento medido. Mantenha o checkout completo da fonte. Reconsidere apenas com menor tempo total de checkout e custo faturado, incluindo busca filtrada, materialização preguiçosa e exportação de harness confiável; menos bytes lógicos sozinhos não estabelecem economia.
• Seleção de proprietário de fixture de declaração (2026-10-02): test/scripts/tsdown-declaration-fixture.ts deriva cópias reais de fonte de seus closures de ponto de entrada em tempo de execução, então PRs de produto que editam um não selecionam as quatro suítes de declaração construídas nele. PR #162614 quebrou write-unified-entry-dts dessa forma; a CI agendada por hora (run 36979748808) o pegou cerca de 35 minutos após o merge, e 0a188c4f038f0 reparou a fixture dentro da hora. Declarar os proprietários como literais new URL(..., import.meta.url) atinge as suítes apenas abaixo do limite de 20 importadores do hub de seleção agressiva: o proprietário do incidente e outros sete são hubs, então o diff reproduzido de #162614 ainda não selecionou nenhum. Reproduzindo todos os 92 commits principais dos 30 dias anteriores que tocaram um proprietário através das opções canônicas do planejador de PR, os literais de URL cobriram recentemente 12 (+35 linhas, +1.689 class-vCPU-minutes). Cobertura total, como uma política de vigilância sobre a mesma lista, seleciona recentemente as suítes para 81 e inicia build-artifacts (mediana de 330s na classe 16 em 12 execuções de PR) para 69, porque as suítes são proprietários de build em ci-build-manifest.mjs: +242 linhas e +11.628 class-vCPU-minutes, uma mediana de +161 (+8%) por PR afetado. Isso compra uma quebra de proprietário escapada em sete semanas, então mantenha os caminhos simples; CI agendada por hora, PRs de proprietários de ferramentas e validação de release são donas desta prova. Reconsidere com uma taxa de escape materialmente maior ou uma seleção que também não inicie build-artifacts.
• Preparação assíncrona de entrada de boundary (2026-09-26): Adicionar as chamadas existentes de CompilerInputSnapshot.prepare() nos três chamadores de declaração/boundary aumentou a validação fria completa de 464,21s para 544,68s no mesmo Testbox de quatro CPUs/15,42 GiB; a validação quente aumentou de 12,62s para 14,63s. Todas as 125 verificações de plugin e o canário passaram, mas o uso de CPU também aumentou. As seis adições de chamadores foram removidas. Não repita isso como uma aceleração assumida; qualquer uso diferente precisa de benefício medido de ponta a ponta.
• Armazenamento pnpm do Windows (2026-09-20): Recibos originais de run 35547255790 mediram a configuração completa mediana em 45,295s frio versus 52,738s restaurado (+16,4%), apesar de reutilizar todos os 1.453 pacotes com zero downloads. O arquivo de 763,8 MiB levou 23,601–26,980s para restaurar; a configuração/salvamento do produtor adicionou 62,527s. Todos os sete jobs nativos passaram, mas o redutor de qualificação falhou em uma diferença de RAM relatada de 24 KiB. Nenhuma asserção foi relaxada ou jobs foram executados novamente. O subconjunto exato de RAM correspondente ainda era 11,3% mais lento; isso é evidência descritiva, não uma substituição que passa na qualificação. Mantenha a configuração normal do Windows sem cache. Reconsidere apenas com economia líquida de configuração completa, incluindo restauração, extração, reconciliação congelada e trabalho do produtor.
• Dependências exatas do Mac hospedado (2026-09-01): O editor e consumidor de mesma head em run 33458856298 salvaram e restauraram com sucesso um arquivo de dependências de 1,66 GB, mas a configuração levou 142s versus 86s com o cache de repositório comum. A extração levou 82s versus 27s; a instalação melhorou apenas de 43s para 35s. Mantenha jobs de Mac hospedados no cache de repositório comum. Reconsidere apenas com economia total de configuração medida, incluindo transferência, extração e reconciliação congelada, não um acerto de cache bem-sucedido.
• Checkout de artefato de Actions (2026-08-16): Não recomende substituir a busca Git compartilhada do Blacksmith por um workspace produzido em pré-voo ou artefato .git. PR #124818 mediu uma linha de base de checkout do Blacksmith de 16s versus 7s hospedado. A melhor variante de artefato direto custou 1s para empacotar, 3s para enviar e 11s mediana para restaurar; incluindo o prefixo serial deixou apenas cerca de 1s de melhoria mediana e regrediu as execuções de busca rápida do Blacksmith. O cliente de artefato oficial foi pior: run 31971531521 mediu 22s mediana de download mais 2s de materialização. O caminho rápido de cache de Actions do Blacksmith não implica downloads rápidos de artefatos de Actions. Reconsidere apenas com prova de ponta a ponta medida para um transporte diferente, incluindo seu custo de produtor e regressões de busca rápida.

Primeiras Verificações

Antes de alterar a CI, colete a pressão atual:

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 uma execução suspeita na fila, inspecione seus jobs. Um status de execução queued não revela se o job está esperando dependências ou se não há runner elegível. Compare created_at, started_at, labels e runner_name. Reverify execuções enfileiradas obsoletas ao vivo antes de cancelá-las; cancele apenas execuções comprovadamente obsoletas.

O warmup do Testbox confirma a criação de concessão, não a prontidão do runner. Um snapshot inicial queued sem providerMetadata.runURL não estabelece uma escassez de capacidade. Use essa URL para inspecionar o workflow exato uma vez associado. Um runner check atribuído realizando configuração é hidratação; uma admissão confirmada ou fila de capacidade segue a política existente de alocação stop-owned. Não infira associação da execução de workflow mais recente nem espere por uma fila de capacidade confirmada.

O atraso inicial de scripts/ci-run-timings.mjs pode incluir tempo de espera de dependência de workflow mais tempo de fila de runner. É evidência de tendência, não prova de pressão de runner sozinha.

Leia:

• .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
• arquivos de planejador tocados sob scripts/lib/*ci*, scripts/lib/*test-plan* ou scripts/ci-changed-scope.mjs

Diagnosticar o Gargalo

Classifique o problema antes de alterar os limites:

• Limitação de registro de runner: muitos jobs enfileirados antes da atribuição de runner, Blacksmith/GitHub relata respostas 403/429 ou 422 do tipo spam de generate-jitconfig, e a cota principal da API ainda está saudável. Trate 422 como este sinal apenas quando o payload da solicitação é válido. Corrija a explosividade e o número de jobs do Blacksmith.
• Capacidade do Blacksmith: o painel do Blacksmith mostra limites reais de concorrência ou capacidade indisponível. Não resolva isso apenas com fanout de workflow do GitHub.
• Plano de controle do Testbox do Blacksmith: chamadas de list, warm, status ou run expiram antes que uma concessão seja retornada. Isso é separado do registro de runner do Actions e da capacidade de job do Actions. A fonte confiável pode usar o fallback local documentado; a fonte não confiável permanece bloqueada.
• Rótulo de runner indisponível: um job está enfileirado com um rótulo runs-on personalizado, started_at e runner_name permanecem vazios, e nenhum runner elegível existe. Restaure um rótulo hospedado ou registrado disponível; fanout não pode resolver isso.
• Espera de dependência de workflow: o job está enfileirado, mas os predecessores necessários não estão terminais. Corrija ou espere pela dependência; não chame todo o atraso de pressão de fila de runner.
• Tempo de execução de teste do OpenClaw: os jobs iniciam rapidamente, mas uma faixa domina o tempo de parede. Use $coin openclaw-test-performance em vez de ajuste de runner.
• CI com falha real: um job falha após iniciar. Use $github:gh-fix-ci ou $coin openclaw-testing, não esta skill.
• Atraso de revisão do ClawSweeper: revisão pendente/pronta cresce enquanto a publicação e os escritores de estado permanecem saudáveis. Ajuste a admissão/workers de revisão em openclaw/clawsweeper.
• Atraso de publicação do ClawSweeper: publicação pendente/pronta e idade mais antiga crescem, a drenagem líquida é zero ou negativa, ou cartas mortas aumentam. Inspecione lotes de publicação, coordenação do escritor de estado e latência de mutação do GitHub primeiro.
• Atraso de materializador/append de estado: state_append.pending_rows, pending_bytes ou idade mais antiga crescem enquanto o materializador está enfileirado ou ausente. Recupere esse dreno único primeiro; mais workers de revisão pioram a situação.

Matemática do Orçamento de Registro

Estime os piores cenários de registro para uma alteração antes de editar:

novos registros do Blacksmith ~= número de jobs do Blacksmith que podem se tornar enfileirados dentro de uma janela de 5 minutos

Para jobs de matriz, conte cada linha que pode iniciar na janela de 5 minutos. strategy.max-parallel apenas limita linhas simultâneas; linhas curtas podem girar e registrar mais runners antes que a janela seja reiniciada. Use duração do job, tentativas e rotatividade da fila para justificar qualquer estimativa menor. Adicione jobs do Blacksmith que não são de matriz, como preflight, security-fast, build-artifacts e faixas de plataforma.

Para repetidores de jobs da API (workflow_dispatch com inputs.job-repeater) que distribuem através do submóduloscripts/ci-job-repeater.mjs, multiplique pelo fator de repetição. O repetidor não impõe sua própria limitação de taxa; um grande repetidor pode esgotar o bucket dentro de uma única janela.

Para jobs que o Blacksmith seleciona apenas como fallback (quando o GitHub não tem um runner compatível), atribua um peso de 1 se a fila de fallback estiver vazia; atribua 0 apenas se o GitHub sempre tiver um runner compatível e não houver fila de fallback. Quando em dúvida, assuma 1. O bucket de registro é compartilhado com todos os outros workflows no openclaw; um fallback registrado por um repetidor conta para o bucket.

Para jobs com rotação de runner (por exemplo, um job que falha e é repetido em um runner diferente), conte cada novo registro. A rotação de runner não reutiliza um JIT token existente.

Para jobs que usam um grupo de runner com um limite de concorrência (concurrency), conte apenas até esse limite. O Blacksmith não honra limites de grupo de runner do GitHub; conte todos os jobs do Blacksmith que podem se tornar enfileirados.

Ações Aprovadas

Aumentar o Paralelismo de Matriz (Pós-Diagnóstico)

1. Confirme que o gargalo é disponibilidade de runner, não registro de runner.
2. Verifique se o Workflow não seleciona uma faixa de plataforma adiada como um pré-requisito.
3. Defina max-parallel para um valor que não exceda 60% do bucket de registro disponível quando todas as linhas estiverem em execução.
4. Para matrizes que alternam entre runners hospedados pelo GitHub e Blacksmith, dimensione para o pior caso de registro do Blacksmith.
5. Adicione um comentário ao workflow explicando por que o novo limite é seguro.
6. Monitore actions_runner_registration por 30 minutos.

Adicionar um Runner do Blacksmith a uma Faixa de CI

1. Confirme que as atribuições de runner existentes são baseadas em dados de tempo de execução ou custo, não em preferência.
2. Verifique se a faixa não depende de um recurso do sistema operacional hospedado que o Blacksmith não fornece.
3. Determine o número esperado de registros de runner Blacksmith por execução.
4. Verifique se o bucket de registro tem espaço suficiente.
5. Adicione o runner, garantindo que o rótulo runs-on corresponda a uma definição de runner existente ou adicionada.
6. Adicione ou atualize docs/ci.md com a nova atribuição e justificativa.
7. Monitore a integridade do bucket de registro e o tempo inicial do job.

Mover um Job Pequeno para um Runner Hospedado pelo GitHub

1. Confirme que o job é curto o suficiente para que o tempo de configuração do runner hospedado não domine.
2. Verifique se o job não aciona limites de cota de API do GitHub, como busca de histórico de issues ou comentários.
3. Para jobs Blacksmith de alta variação, verifique se o runner hospedado tem largura de banda e CPU suficientes.
4. Mude o rótulo runs-on e remova qualquer configuração de runner Blacksmith.
5. Atualize a documentação.
6. Meça o tempo de execução e o custo por pelo menos 10 execuções.

Limites de Derretimento (Ramp-Down / Ramp-Up)

• Para desligar uma classe inteira de runner: comente a definição do runner ou coloque a capacidade como 0 no Blacksmith, então cancele jobs enfileirados.
• Para reativar: remova o comentário ou restaure a capacidade e cancele novamente apenas se necessário.
• Não cancele jobs que já estão sendo executados, a menos que sejam perigosos.
• Use max-parallel para limitar temporariamente, não a capacidade do Blacksmith.
• Para retardar uma onda de jobs, defina concurrency no nível do workflow ou defina max-parallel para 1.
• Documente cada ação de derretimento. Use um rastreamento de issues ou um arquivo ops/ci-meltdown.log.

Verificações de Pós-Alteração

# Verificar integridade do bucket de registro
g api rate_limit --jq '{actions_runner_registration:.resources.actions_runner_registration}'
# Verificar status do Blacksmith
curl -fsS https://clawsweeper.openclaw.ai/api/status | jq '{generated_at, fleet, diagnostics}'
# Verificar fila de revisão
curl -fsS https://clawsweeper.openclaw.ai/api/exact-review-queue | jq '{generated_at, review:.lanes.review.latest.age_s, publication:.lanes.publication.latest.age_s}'
# Verificar jobs enfileirados para o novo workflow
g run list -R openclaw/openclaw --workflow <workflow-name> --limit 5 --json databaseId,status,conclusion,createdAt,updatedAt

Se a fila de revisão ficar para trás após uma mudança de runner, pare de adicionar runners e verifique as capacidades de worker de revisão do ClawSweeper.

Limpeza

Após uma alteração de capacidade confirmada como segura, cancele quaisquer execuções de CI órfãs que estejam usando recursos antigos (por exemplo, uma execução de workflow lançada antes de um derretimento com um runner agora desativado). Use:

g run cancel <run-id> -R openclaw/openclaw

Após um experimento rejeitado, reverta todas as alterações e cancele quaisquer execuções órfãs. Não deixe documentos de design ou código de experimento em .github/workflows/.

Leituras Relacionadas

• docs/ci.md - Visão geral da CI do OpenClaw
• docs/ci/scope-and-routing/selection.md - Seleção de workflow por evento, proprietário e fallback
• docs/reference/test/remote-proof.md - Testboxes e prova remota
• scripts/ci-run-timings.mjs - Tempos de execução de CI
• scripts/ci-changed-scope.mjs - Escopo alterado por PR
• test/scripts/ci-workflow-guards.test.ts - Testes de salvaguarda de workflow
• test/scripts/ci-workflow-planning.test.ts - Testes de planejamento de workflow
• test/scripts/ci-workflow-evidence.test.ts - Testes de evidência de workflow