openclaw-ci-limits

OpenClaw CI-Limits

Dieser Skill ist ausschließlich für CI-Kapazitätsänderungen gedacht, nicht für die normale Fehlerbehebung bei fehlgeschlagenen Tests. Ziel ist es, OpenClaw schnell zu halten und dabei Runner-Registrierung, Runner-Verfügbarkeit, Blacksmith Control-Plane-Gesundheit und die Entleerung nachgelagerter Warteschlangen zu unterscheiden.

Kernfakten

• Der vollständige Main-Tier-CI läuft stündlich; normale Main-Pushes führen security-fast aus. Ein grüner Push ist kein Beleg dafür, dass die gesamte Suite bestanden hat. Normale PRs verschieben Windows, macOS Node/Swift, iOS Build/Simulator, echtes Gateway-UI, veröffentlichte Treiberaktualisierungen, Knip und die meisten Architekturprüfungen. Import-Zyklus- und Kysely-Guards bleiben blockierend. Verwenden Sie docs/ci/scope-and-routing/selection.md und das aktuelle Manifest für die genaue Ereignis-, Besitzer- und Release-Fallback-Auswahl; stellen Sie verschobene Lanes während der Kapazitätsoptimierung nicht wieder her. Android-Screenshots bleiben Release-only.
• Gehen Sie nicht von der Engpassressource aus. Beweisen Sie, ob der Druck durch Runner-Registrierungen, verfügbare qualifizierte Runner, Blacksmith-Kapazität/Control-Plane, Workflow-Abhängigkeiten, Testlaufzeit oder einen nachgelagerten Warteschlangenschreiber verursacht wird.
• GitHub Runner-Registrierungen für openclaw melden derzeit 10.000 pro 5-Minuten-Bucket in actions_runner_registration. Überprüfen Sie den live Bucket vor jedem Optimierungslauf, da GitHub den Wert ändern kann. Die openclaw-Organisation teilt sich einen Bucket.
• Das Core-REST-Kontingent wird nicht von diesem Bucket abgezogen. Überprüfen Sie actions_runner_registration separat; das Core-Kontingent kann gesund sein, während die Runner-Registrierung gedrosselt wird.
• Verwenden Sie etwa 60 % des live Buckets als Betriebsziel. Beim aktuellen Bucket von 10.000 Registrierungen halten Sie die geplante Blacksmith-Burst-Last unter 6.000 Registrierungen pro 5 Minuten und lassen den Rest für andere Repos, Wiederholungen und Burst-Überlappungen.
• Jobs, die routen, benachrichtigen, zusammenfassen, Shards auswählen oder kurze CodeQL-Qualitätsscans durchführen, sollten auf GitHub-gehosteten Runnern bleiben, es sei denn, gemessene Belege zeigen, dass Blacksmith erforderlich ist.

Runner-Kostenrichtlinie

• Verwenden Sie den kleinsten Runner, der die erforderliche Workload zuverlässig abschließt. Lassen Sie kurze Steuerungsjobs gehostet und gewöhnliche vertrauenswürdige Entwicklungsnachweise lokal.
• Behandeln Sie physische 8-vCPU- und größere Runner als Ausnahmen, nicht als Standard oder generische Wiederholung. Dokumentieren Sie den Befehl und den gemessenen Spitzenarbeitsspeicher, einen OOM auf einem kleineren Runner oder einen kontrollierten Vergleich, der niedrigere Gesamtabrechnungskosten zeigt. Eine niedrige CPU-Auslastung allein beweist nicht, dass ein speicherintensiver Job auf einen kleineren Runner verschoben werden kann. Behalten Sie ressourcenbasierte Worker-Limits bei.
• Routinemäßige OpenClaw-Testboxen verwenden die 4-Klasse mit einem Standard-60-Minuten-Gesamtjob, einschließlich Hydratation. Halten Sie die 15-Minuten-Leerlaufobergrenze ein. Kürzere Fristen sind für bekannte kurze Befehle willkommen; fordern Sie nicht automatisch vier Stunden an oder vergrößern Sie nur, um mehr Zeit zu erhalten. Wählen Sie .github/workflows/ci-check-high-memory-testbox.yml nur explizit für einen benannten speicherintensiven Befehl aus; siehe docs/reference/test/remote-proof.md. Dieser Workflow hat maximal vier gleichzeitige Leases im gemeinsamen 32-Slot-Testbox-Pool. Das Hocharbeitsspeicher-Profil verwendet 8 vCPUs; beide Profile bewahren ihre physische CPU und RAM vor November 2023. Alle Testbox-Profile begrenzen die Leerlaufzeit auf 15 Minuten.
• Weisen Sie über den aktuellen OpenClaw-Wrapper mit dem Workflow-Ref main zu; die Quellkapsel bewahrt den zu testenden Checkout. Lösen Sie keinen alten Workflow-Ref aus, um Ausgabenlimits zu umgehen. Das Warteschlangenalter wird vor dem Checkout überprüft; ein zugelassener Lease behält seine Job- und Leerlauffristen.
• Bewerben Sie nicht eine gesamte Workflow-Familie, weil ein Befehl mehr RAM benötigt. Halten Sie nachgewiesene speicherintensive CI-Zeilen auf ihren zugehörigen Planer und Belege beschränkt; messen Sie neu, bevor Sie ihre Zuweisung ändern. Ein 32-Klasse-Label ist kein Beleg für 32 verfügbare CPUs. Vergleichen Sie beobachtete Ressourcen und die gesamten abgerechneten Jobkosten.

Abgelehnte Experimente

• UI Blobless Sparse Checkout (2026-10-16): Das Ausschließen nativer mobiler/macOS-App-Bäume entfernte 48,31 MiB logisch getrackten Inhalts, qualifizierte sich jedoch nicht als Runner-Kostenverbesserung. In Run 38866595993 dauerte der Blacksmith-UI-E2E-Checkout 56s und der gehostete Browser-Checkout 58s; vollständige UI-Checkouts im selben Lauf dauerten 22–38s. Dies sind kleine, ungepaarte Stichproben, keine gemessene Abrechnungsdifferenz. Behalten Sie den vollständigen Quell-Checkout bei. Erwägen Sie dies nur mit niedrigerer vollständiger Checkout-Zeit und abgerechneten Kosten, einschließlich gefiltertem Fetch, lazy Materialisierung und vertrauenswürdiger Harness-Export; weniger logische Bytes allein belegen keine Einsparungen.
• Deklarations-Fixture-Besitzerauswahl (2026-10-02): test/scripts/tsdown-declaration-fixture.ts leitet echte Quellkopien von seinen Laufzeit-Einstiegspunkt-Closures ab, sodass Produkt-PRs, die eine davon bearbeiten, die vier darauf aufbauenden Deklarations-Suiten nicht auswählen. PR #162614 hat write-unified-entry-dts auf diese Weise unterbrochen; der stündlich geplante CI (Run 36979748808) hat es etwa 35 Minuten nach dem Merge erkannt und 0a188c4f038f0 reparierte das Fixture innerhalb der Stunde. Die Angabe der Besitzer als new URL(..., import.meta.url)-Literale erreicht die Suiten nur unterhalb der aggressiven Auswahlgrenze von 20 Importern: Der Vorfallbesitzer und sieben andere sind Hubs, daher wählte der wiederholte #162614-Diff immer noch keine aus. Beim Wiederholen aller 92 Main-Commits der letzten 30 Tage, die einen Besitzer über die kanonischen PR-Planer-Optionen berührten, deckten URL-Literale 12 neu ab (+35 Zeilen, +1.689 Klasse-vCPU-Minuten). Vollständige Abdeckung, wie z. B. eine Richtlinienüberwachung über derselben Liste, wählt die Suiten für 81 neu aus und startet build-artifacts (Median 330s auf der 16-Klasse über 12 PR-Läufe) für 69, da die Suiten Build-Besitzer in ci-build-manifest.mjs sind: +242 Zeilen und +11.628 Klasse-vCPU-Minuten, ein Median von +161 (+8 %) pro betroffenem PR. Das erkauft einen entkommenen Besitzerbruch in sieben Wochen, also behalten Sie die einfachen Pfade; der stündlich geplante CI, Tooling-Besitzer-PRs und Release-Validierung sind für diesen Beleg zuständig. Erwägen Sie dies nur mit einer wesentlich höheren Entkommensrate oder einer Auswahl, die nicht auch build-artifacts startet.
• Asynchrone Eingabevorbereitung für Boundary (2026-09-26): Das Hinzufügen der vorhandenen CompilerInputSnapshot.prepare()-Aufrufe an den drei Deklarations-/Boundary-Aufrufern erhöhte die vollständige Kaltvalidierung von 464,21s auf 544,68s auf derselben 4-CPU/15.42-GiB-Testbox; die Warmvalidierung stieg von 12,62s auf 14,63s. Alle 125 Plugin-Checks und der Canary bestanden, aber die CPU-Auslastung stieg ebenfalls. Die sechs Aufrufer wurden entfernt. Wiederholen Sie dies nicht als angenommene Beschleunigung; jede andere Verwendung benötigt einen gemessenen End-to-End-Vorteil.
• Windows pnpm Store (2026-09-20): Ursprüngliche Belege von Run 35547255790 maßen die mediane vollständige Einrichtung mit 45,295s kalt gegenüber 52,738s wiederhergestellt (+16,4 %), trotz Wiederverwendung aller 1.453 Pakete ohne Downloads. Das 763,8-MiB-Archiv wurde in 23,601–26,980s wiederhergestellt; die Erstellung/Speicherung durch den Produzenten dauerte 62,527s. Alle sieben nativen Jobs bestanden, aber der Qualifikations-Reduzierer scheiterte an einer 24-KiB-gemeldeten RAM-Differenz. Es wurden keine Assertions gelockert oder Jobs wiederholt. Die exakt RAM-gematchte Teilmenge war immer noch 11,3 % langsamer; das ist beschreibender Beleg, kein Ersatz für bestandene Qualifikation. Behalten Sie die normale Windows-Einrichtung ungecacht. Erwägen Sie dies nur mit Netto-Einsparungen bei der Gesamteinrichtung, einschließlich Wiederherstellung, Extraktion, frozen Reconciliation und Produzentenarbeit.
• Hosted Mac Exakte Abhängigkeiten (2026-09-01): Der Publisher und Consumer mit demselben HEAD in Run 33458856298 haben erfolgreich ein 1,66-GB-Abhängigkeitsarchiv gespeichert und wiederhergestellt, aber die Einrichtung dauerte 142s gegenüber 86s mit dem gewöhnlichen Store-Cache. Die Extraktion dauerte 82s gegenüber 27s; die Installation verbesserte sich nur von 43s auf 35s. Behalten Sie gehostete Mac-Jobs auf dem gewöhnlichen Store-Cache. Erwägen Sie dies nur mit gemessenen Gesamteinsparungen bei der Einrichtung, einschließlich Transfer, Extraktion und frozen Reconciliation, nicht mit einem erfolgreichen Cache-Treffer.
• Actions-Artifact Checkout (2026-08-16): Empfehlen Sie nicht, den gemeinsamen Blacksmith Git-Fetch durch ein vorab erstelltes Workspace- oder .git-Artefakt zu ersetzen. PR #124818 maß eine Blacksmith-Checkout-Basislinie von 16s gegenüber 7s gehostet. Die beste direkte Artefakt-Variante kostete 1s zum Packen, 3s zum Hochladen und 11s median zur Wiederherstellung; einschließlich des seriellen Präfix blieb nur etwa 1s mediane Verbesserung und verschlechterte die Blacksmith-Schnell-Fetch-Läufe. Der offizielle Artefakt-Client war schlechter: Run 31971531521 maß 22s medianen Download plus 2s Materialisierung. Der Blacksmith-Schnell-Actions-Cache-Pfad impliziert nicht schnelle Actions-Artefakt-Downloads. Erwägen Sie dies nur mit gemessenen End-to-End-Beleg für ein anderes Transportmittel, einschließlich seiner Produzentenkosten und Schnell-Fetch-Verschlechterungen.

Erste Checks

Sammeln Sie vor der Änderung der CI den aktuellen Druck:

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

Überprüfen Sie bei einem verdächtig in der Warteschlange befindlichen Lauf dessen Jobs. Ein queued-Status auf Laufebene zeigt nicht an, ob der Job auf Abhängigkeiten wartet oder kein geeigneter Runner verfügbar ist. Vergleichen Sie created_at, started_at, labels und runner_name. Überprüfen Sie veraltete queued Läufe live, bevor Sie sie abbrechen; brechen Sie nur Läufe ab, die als obsolet nachgewiesen wurden.

Testbox-warmup bestätigt die Lease-Erstellung, nicht die Runner-Bereitschaft. Eine anfängliche queued-Momentaufnahme ohne providerMetadata.runURL belegt keine Kapazitätsknappheit. Verwenden Sie diese URL, um den genauen Workflow zu überprüfen, sobald er zugeordnet ist. Ein zugewiesener check-Runner, der Setup durchführt, ist Hydratation; eine bestätigte Aufnahme oder Kapazitätswarteschlange folgt der bestehenden Stop-Owned-Allocation-Richtlinie. Folgern Sie keine Zuordnung aus dem neuesten Workflow-Lauf oder warten Sie auf eine bestätigte Kapazitätswarteschlange.

Die Startverzögerung von scripts/ci-run-timings.mjs kann die Wartezeit auf Workflow-Abhängigkeiten plus Runner-Warteschlangenzeit umfassen. Es handelt sich um Trendbelege, nicht allein um einen Beweis für Runner-Druck.

Lesen Sie:

• .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
• betroffene Planerdateien unter scripts/lib/*ci*, scripts/lib/*test-plan* oder scripts/ci-changed-scope.mjs

Engpass diagnostizieren

Klassifizieren Sie das Problem, bevor Sie Limits ändern:

• Runner-Registrierungsdrosselung: Viele Jobs in der Warteschlange vor der Runner-Zuweisung, Blacksmith/GitHub meldet 403/429 oder Spam-artige 422-Antworten von generate-jitconfig, und das API-Kernkontingent ist noch gesund. Behandeln Sie 422 nur dann als dieses Signal, wenn die Anfrage-Payload ansonsten gültig ist. Beheben Sie Burstiness und die Anzahl der Blacksmith-Jobs.
• Blacksmith-Kapazität: Das Blacksmith-Dashboard zeigt tatsächliche Parallelitätslimits oder nicht verfügbare Kapazität. Lösen Sie dies nicht allein mit GitHub-Workflow-Fanout.
• Blacksmith Testbox Control Plane: List-, Warm-, Status- oder Run-Aufrufe laufen ab, bevor ein Lease zurückgegeben wird. Dies ist getrennt von der Actions-Runner-Registrierung und der Actions-Job-Kapazität. Vertrauenswürdige Quellen können den dokumentierten lokalen Fallback verwenden; nicht vertrauenswürdige Quellen bleiben blockiert.
• Nicht verfügbares Runner-Label: Ein Job wird mit einem benutzerdefinierten runs-on-Label in die Warteschlange gestellt, started_at und runner_name bleiben leer, und es existiert kein geeigneter Runner. Stellen Sie ein verfügbares gehostetes oder registriertes Label wieder her; Fanout kann dies nicht beheben.
• Workflow-Abhängigkeitswartezeit: Der Job ist in der Warteschlange, aber erforderliche Vorgänger sind nicht abgeschlossen. Beheben oder warten Sie auf die Abhängigkeit; bezeichnen Sie die gesamte Verzögerung nicht als Runner-Warteschlangendruck.
• OpenClaw-Testlaufzeit: Jobs starten schnell, aber eine Lane dominiert die Wandzeit. Verwenden Sie $openclaw-test-performance anstelle von Runner-Optimierung.
• Tatsächlicher CI-Fehler: Ein Job schlägt nach dem Start fehl. Verwenden Sie $github:gh-fix-ci oder $openclaw-testing, nicht diesen Skill.
• ClawSweeper-Review-Rückstand: Ausstehende/fertige Reviews wachsen, während Veröffentlichung und Zustandsschreiber gesund bleiben. Optimieren Sie Review-Aufnahme/Worker in openclaw/clawsweeper.
• ClawSweeper-Veröffentlichungsrückstand: Ausstehende/fertige Veröffentlichungen und ältestes Alter wachsen, der Nettoabfluss ist null oder negativ, oder Dead Letters steigen. Überprüfen Sie zuerst Veröffentlichungschargen, Zustandsschreiber-Koordination und GitHub-Mutationslatenz.
• Zustandsmaterialisierer/Append-Rückstand: state_append.pending_rows, pending_bytes oder ältestes Alter wachsen, während der Materialisierer in der Warteschlange oder abwesend ist. Stellen Sie diesen einzigen Abfluss zuerst wieder her; mehr Review-Worker verschlimmern es.

Berechnung des Registrierungsbudgets

Schätzen Sie die Worst-Case-Registrierungen für eine Änderung vor der Bearbeitung:

neue Blacksmith-Registrierungen ≈ Anzahl der Blacksmith-Jobs, die innerhalb eines
5-Minuten-Fensters in die Warteschlange gelangen können

Zählen Sie bei Matrix-Jobs jede Zeile, die innerhalb des 5-Minuten-Fensters starten kann. strategy.max-parallel begrenzt nur gleichzeitige Zeilen; kurze Zeilen können umschlagen und mehr Runner registrieren, bevor das Fenster zurückgesetzt wird. Verwenden Sie Jobdauer, Wiederholungen und Warteschlangenumschlag, um eine niedrigere Schätzung zu rechtfertigen. Fügen Sie Nicht-Matrix-Blacksmith-Jobs wie preflight, security-fast, build-artifacts und Plattform-Lanes hinzu.

Für Wiederholungen ...