release-openclaw-ci

OpenClaw Release CI

Verwenden Sie dies mit $release-openclaw-maintainer und $openclaw-testing, wenn ein Release-Kandidat eine vollständige Validierung, Installations-/Update-Nachweise, Live-Provider-Prüfungen oder CI-Wiederherstellung benötigt.

Schutzschienen (Guardrails)

• Keine Versionserhöhung, kein Tag, kein npm-Publish, kein GitHub-Release oder keine Release-Promotion ohne explizite Zustimmung des Operators.
• Nach einer Kompaktierung, Wiederaufnahme oder neuen Steuerung schreiben Sie das effektive Ziel und die aktuelle Phase aus der letzten expliziten Operator-Anweisung um. Führen Sie keinen alten Umfang wieder in den aktiven Release zusammen.
• Halten Sie den Release-Umfang fest, sobald ein Release-Branch oder Code-SHA existiert. Validieren und liefern Sie genau diesen Release aus; machen Sie aus dem sich bewegenden main keine zweite Arbeitswarteschlange.
• Dokumentieren Sie C (Kandidat), Q (Testqualifikation), P (Zulassung/Prüfung/Verifizierer/Publisher), Wiederholungsgruppe, Profil, effektive Soak-Zeit sowie Kontext-/Transport-Referenzen. Die neue Testqualifikation für Kandidaten standardmäßig auf Q=C, einschließlich des vollständigen Workflows, wiederverwendbaren Workflows, lokalen Aktionen, Skripts, Planers, Vertrags und der Testabdeckung. Code-SHA und Release-SHA bleiben Lebenszyklus-Rollen, keine zusätzlichen Workflow-Identitäten.
• Der Kandidaten-Helfer akzeptiert ein fehlendes Release-Tag oder ein existierendes leichtes oder annotiertes Tag, das auf den exakten Kandidaten-SHA auflöst. Ein widersprüchliches Tag oder ein fehlgeschlagener Remote-Lookup stoppt die Validierung; verschieben Sie niemals ein Tag, um dies zu korrigieren.
• Frieren Sie C/Q ein und wählen Sie unabhängig einen vertrauenswürdigen P auf main oder einem geschützten Publikations-Tag aus. C/Q müssen kein Vorfahre von P sein. Fehlende Kandidaten-Verträge erfordern einen bewussten Backport; ersetzen Sie niemals stillschweigend neuere Haupt-Tooling.
• Wenden Sie nach dem Einfrieren des Code-SHA eine Release-Firebreak an. Lassen Sie nur bestätigte Produktfehler, falsche oder nicht verifizierbare Paket-Bytes, Sicherheitsmängel oder Fehler zu, die eine Veröffentlichung unmöglich machen. Andere Ergebnisse für die Zeit nach der Veröffentlichung oder die nächste Beta einreihen. Abhängigkeitshinweise sind niemals Firebreak-Zulassungen: Dokumentieren Sie sie als Release-Nachweise und reihen Sie den Bump auf main nach der Veröffentlichung ein; nur bekannte Malware stoppt die Veröffentlichung.
• Eingefrorene CI-Kinder verwenden den Node-Shard-Planer und die gemessenen Kosten von Q, während sie Tests aus dem Kandidaten-Checkout entdecken und ausführen. Gehostete Voll-Release-Pläne teilen gemessene Zeilen über 12 Minuten auf; bewahren Sie Dateiabdeckung, Worker-Limits und vollständige Zeitmessungen auf. Ein unteilbarer über dem Budget liegender Eigner muss aufgeteilt werden, anstatt das Release-Budget zu erhöhen. Nach Abschluss des Kindes führt der Abschluss scripts/ci-shard-timings-refresh.mts für diesen exakten Lauf aus und übernimmt generierte Kosten; bearbeiten Sie Messungen nicht von Hand.
• Kandidaten-Tests führen ihren eigenen eingefrorenen Q-Abschluss aus; zugelassenes P besitzt die aggregierte Entscheidung von FRV und die eingecheckte Verzichtserklärung. Nur-Main-Checks und Zukunfts-Main-Szenarien sind keine impliziten Release-Anforderungen. Das Beheben eines eingefrorenen Qualifikations-Harnesses bedeutet ein neues C/Q mit neu gebundenen Nachweisen. Eine reine P-Reparatur (Zulassung/Prüfung/Verifizierer/Publisher) kann C/Q und ihre ursprünglichen Nachweise behalten.
• Geschützte leichte release-publish/<12sha>-<provenance-run>-Tags identifizieren P, nicht Q. Das Suffix dokumentiert die Tag-Erstellungs-Provenienz, nicht den aktuellen Eltern. Publikations-Helfer behalten ihr --workflow-sha <P>-Argument; das --workflow-sha des FRV-Helfers wählt stattdessen Q aus und muss auf dem Kandidaten-Route gleich C sein.
• Berühren Sie main nur für eine vom Operator angeforderte Änderung oder den kleinsten kritischen Main-eigenen Blockierer, der diesen Release verhindert und nicht über den Release-Branch behandelt werden kann. Der CI-Zustand von main blockiert niemals einen Release. Wenn ein Release-Tooling-Landing durch main-Fehler blockiert wird, die es nicht verursacht, beweisen Sie auf einem sauberen main-Checkout, dass der Fehler dort bereits existiert, dokumentieren Sie ihn im PR-Body und führen Sie den Merge durch; während eines aktiven Releases ist ein Admin-Merge für diesen exakten Fall erlaubt. Ein separater Lane repariert roten main parallel, außerhalb des kritischen Pfads des Releases.
• Landen Sie reine Tooling-Fixes auf main mit dem vor dem Push hinzugefügten release-fast-lane-Label (siehe Release-Tooling-Fast-Lane): openclaw/ci-gate führt dann nur Lint, Types, Guards, Dependencies, Docs und die geänderten Node-Zeilen aus. Landen Sie über den nativen Maintainer-Workflow. Dieser Workflow besitzt die Review- und Landing-Anforderungen, einschließlich der Richtlinie für ClawSweeper-Hinweise; das Label ändert nur die CI-Auswahl.
• OPENCLAW_RELEASE_RUNNER_GROUP leitet optional Validierungs-Eltern und -Worker sowie den Release-Publish-Eltern plus seine Publish-Kinder an reservierte Kapazität mit unveränderten Labels; anmeldebasierte Publish- und Genehmigungs-Jobs bleiben auf den Standard-GitHub-gehosteten Labels. Konfigurieren Sie zuerst berechtigte Runner und Repository-Zugriff; nicht gesetzt bewahrt die normale Weiterleitung. Geteilte Worker erben die Aufrufer-Gruppe; PR/Main-CI und unzusammenhängende geplante Arbeit bleiben außerhalb.
• Überprüfen Sie den nächtlichen Eltern auf den Code-SHA, bevor Sie eine neue Main-Validierung auslösen; dieser versiegelt pro-Kind-Belege, die exakte Ziel-Dispatches übernehmen, wenn die Eingaben übereinstimmen. Der nächtliche Lauf verwendet diesen expliziten vertrauenswürdigen Main-Helfer-Route (--sha <main-sha> --workflow-sha <main-sha> --trusted-workflow-ref main), daher läuft sein Eltern auf einem release-ci/<sha12>-<id>-Branch, nicht main.
• FRV muss unter festgelegter P's eingecheckter Verzichtserklärung erfolgreich abschließen; alle anderen erforderlichen Lanes müssen bestanden werden. Siehe Publikationsanforderungen. Stabile Tags erfordern stabile/full-Nachweise, Soak und blockierende Leistung. Beta-Profil-Nachweise können keine Stabilität qualifizieren. Soak und Leistung sind nicht verzichtbar. Die Qualifikation aller Gruppen erfordert alle neun Linux/Windows/macOS Gateway-Install/Upgrade-Kombinationen. Bewahren Sie erste Fehler, Identität und vollständige Nachweise auf.
• Native macOS-, Windows-, Linux- und Android-Veröffentlichung ist unabhängig von npm/ClawHub, GitHub-Finalisierung und Main-Abschluss. Jede Plattform behält ihre eigenen Signatur-, Qualifikations-, Artefakt- und Updater-Anforderungen; melden Sie ausstehende Plattformen genau und reparieren Sie native Fehler parallel.
• Setzen Sie keine GitHub Secrets aus nicht validierten 1Password-Kandidaten. Wenn ein Kandidat 401/403 zurückgibt, lassen Sie das vorhandene Secret unverändert und melden Sie den genauen fehlenden Provider.
• Verwenden Sie $one-password für Secret-Lese-/Schreibvorgänge: eine persistente tmux-Sitzung, nur gezielte Items, keine Secret-Ausgabe.
• Beobachten Sie einen Eltern-Lauf mit pnpm frv watch --run <parent> (siehe Beobachten). Vermeiden Sie breite gh run view-Polling-Schleifen; das REST-Kontingent ist leicht zu erschöpfen.
• Rufen Sie Logs nur für fehlgeschlagene oder aktuell blockierende Jobs ab. Bei niedrigem Kontingent stoppen Sie das Polling und warten auf den Reset.
• Behandeln Sie Live-Provider-Flakes getrennt von Code-Fehlern: Beweisen Sie Schlüsselgültigkeit, Provider-HTTP-Status, Wiederholungsnachweise und den genauen fehlgeschlagenen Lane, bevor Sie Code bearbeiten.
• Wenn Sie einen Live-Provider-Fehler diagnostizieren, beweist eine Modelllisten-Antwort die Authentifizierung, nicht die Abrechnung oder Inferenzberechtigung. Bestätigen Sie die Anmeldedaten mit einem echten Completion-Probe, bevor Sie sie als gültig behandeln. Korrigieren Sie zuerst die Anmeldedaten; fügen Sie keinen alternativen Auth-Pfad nur hinzu, um einen fehlgeschlagenen Release-Anmeldedatensatz zu umgehen.
• Full Release Validation trennt exakten Kind-Dispatch, Release-Entscheidung und Diagnose-Drain. Mit fail_fast=false tätigt es null Kind-Abbruch-Aufrufe; Diagnose-Drain folgt jedem ausgewählten Kind bis zum Terminal, es sei denn, der Collector selbst wird abgebrochen oder verliert den GitHub-API-Zugriff. Mit fail_fast=true kann die Release-Entscheidung nur das exakte noch aktive Kind abbrechen, das einen blockierenden Fehler besitzt.
• Die Fortsetzung desselben Elternteils erfordert, dass die ursprüngliche Wurzel mit fail_fast=false ausgelöst wurde. Der Controller überprüft diese exakte protokollierte Eingabe vor jeder Wiederholungs-Mutation.
• Ein Elternteil, der seine eigenen versiegelten Kandidaten-Artefakte produziert hat, kann nicht fortgesetzt werden: GitHub-Wiederholungen machen diese Artefakte vorheriger Versuche nicht verfügbar. Halten Sie den Kandidaten- und Qualifikations-SHA eingefroren, ersetzen Sie diesen Elternteil und starten Sie eine frische Full Release Validation aller Gruppen.
• Nach dem Dispatch dokumentiert ein unveränderliches Ausführungsplan-Artefakt den ursprünglichen Eltern-Versuch, exakte Kind-Tupel und -Titel, ausgewählte Abdeckung, Gates und Wiederverwendungs-Identität. Dieselben Bytes werden unter einem exakten Run-ID-Cache-Schlüssel gespeichert. Entscheidung, Drain, Manifest-Schreiben, Nachweisvalidierung und endgültige Verifizierung konsumieren das Artefakt für ihren aktuellen Versuch. Ein Collector-Wiederholungsversuch stellt den gecachten Plan wieder her, validiert ihn, lädt sein Artefakt erneut hoch und übernimmt dieselben Kinder; fehlender Plan-Zustand ist ein Orchestrierungsfehler, keine Berechtigung, den Plan zu rekonstruieren oder erneut auszulösen.
• Wiederverwendete Nachweise werden nicht allein deshalb vertraut, weil die Planversiegelung sie gefunden hat. Die Release-Entscheidung wiederholt den versiegelten Ziel-SHA, Nachweis-SHA, Richtlinie, geänderte Pfade, ausgewählten Lauf, Wurzel-Lauf, Quell-Manifest, vertrauenswürdige Tooling-Identität und exakte Kind-Prüfungen, bevor sie passed zurückgibt.
• Eltern-Wiederholungen wählen die neuesten Entscheidungs- und Drain-Artefakte unabhängig aus; beide müssen denselben unveränderlichen Plan binden, auch wenn ihre Quell-Versuche unterschiedlich sind.
• Kind-Wiederholungen sind nur dann Teil desselben unveränderlichen Plans, wenn die Kind-Run-ID, der Workflow-Pfad, der Ref, der Q-SHA, der Dispatch-Titel, das Ereignis, das Ziel, der Kandidat und die Validierungseingaben exakt bleiben. Neuere Kind-Versuche ersetzen passende Jobs; Jobs, die in einem neueren Versuch fehlen, werden fortgeführt. Eine doppelte Job-Identität, ein fehlender Versuch, ein verschlechterter Versuch oder ein geändertes Tupel schlägt geschlossen fehl. frv status und continue erlauben bis zu 60 Sekunden schreibgeschützte Abgleichung, wenn GitHub vorübergehend doppelte Jobs im neuesten Wiederholungsversuch zurückgibt. Das Lauf-Tupel und der Versuch bleiben festgesetzt; persistente Duplikate und Konflikte älterer Versuche bleiben Fehler.
• Verwenden Sie pnpm frv status|watch|rerun --job|rerun --child|continue --failed|verify für versuchsbewusste Wiederherstellung. Der Controller ist zustandslos: Der unveränderliche Ausführungsplan, exakte GitHub-Run-Versuche, Diagnose-Drain und das endgültige Manifest sind die einzigen Autoritäten. Er schreibt niemals ein Tag, Paket, Registry-Eintrag, Release-Kandidat oder Veröffentlichung.
• Der Post-Merge-Controller-Nachweis muss den überprüften gelandeten SHA auf geschütztem main durch den nicht-Release-FRV Proof Broker und FRV Proof Fixture verwenden. Lösen Sie den Broker mit der gemergten Pull-Request-Nummer und dem exakten gelandeten Commit aus. Der Broker muss verlangen, dass der Merge-Commit dieses Pull-Requests mit dem gelandeten Commit übereinstimmt, beweisen, dass der gelandete Commit identisch oder ein Vorfahre seines vertrauenswürdigen Workflow-SHA ist, und Autoritäts-, Merge- und Abstammungsprüfungen unmittelbar vor der erneuten Ausführung des Fixtures wiederholen. Verlangen Sie, dass der exakte feste No-Op-Fixture-Lauf von seinem beabsichtigten Versuch-eins-Fehler zu einem Versuch-zwei-Bestehen fortschreitet. Der Broker muss seine Quittung ausgeben, ohne einen Release-Kandidaten, Release-Artefakt, Veröffentlichung, Repository-Ref, ersetzenden Elternteil oder andere Workflow-Mutation zu erstellen. Dies ist der gehostete GitHub-gezielte Job-Wiederholungs-Nachweis; fokussierte Controller-Tests besitzen die Berechtigung für unveränderliche Pläne, Erhaltung grüner Versuche, Sammlung gleicher Eltern und strikte Verifizierer-Aufrufe. Verwenden Sie niemals einen echten Full Release Validation-Lauf für diesen Nachweis. Siehe Full Release Validation.
• Verwenden Sie einen Release-Operator, ein frv watch und höchstens einen Ermittler für die aktuelle fehlgeschlagene Oberfläche. Bauen Sie keine Audit-Review-Plan-Bäume um einen einzelnen Workflow-Übergang.
• Bei regulären Beta-/Stable-Releases kann der Code-SHA bereits endgültige Notizen enthalten und als Release-SHA dienen. Ein erfolgreicher frischer vollständiger Elternlauf kann beide Rollen und ihre exakten Veröffentlichungs-Bytes qualifizieren. Wenn sich Notizen danach ändern, kann ein späterer Release-SHA Produktnachweise wiederverwenden, nur wenn sein vollständiges Delta zum Code-SHA das ausgewählte CHANGELOG/YYYY.M.PATCH.md und optional CHANGELOG.md und CHANGELOG/records/YYYY.M.PATCH.md ändert, ohne andere Pfade, Umbenennungen oder Löschungen; seine geänderten Bytes benötigen dennoch Qualifikation.
• Extended-stable validiert eine exakte Branch-Spitze; es verwendet nicht das reguläre Code-SHA/Release-SHA-Nachweismodell.
• Bei einer spärlichen Worktree- oder Testbox-Quellensynchronisierung bestätigen Sie zuerst package.json, pnpm-lock.yaml und jeden Quellpfad, den die ausgewählte Prüfung liest. Wenn einer fehlt, kann dieser Checkout keine Release-Abhängigkeit oder Docker-Lane validieren: Stoppen Sie und verwenden Sie das Remote-Geänderte-Gate des Repos oder einen vollständigen Task-Worktree. Wenn die Eingaben vorhanden sind und ein Release-Fix package.json oder pnpm-lock.yaml ändert, bauen Sie nur die task-eigene Einweg-Box mit CI=true pnpm install --frozen-lockfile neu auf und führen Sie dann einen expliziten require.resolve()-Probe vor Docker oder fokussierten Tests durch. Das CI-Flag erlaubt pnpm, ein vorgewärmtes Modules-Verzeichnis ohne interaktive Bestätigung neu zu erstellen. Schwächen Sie die Lockfile nicht und kennzeichnen Sie spärliche Checkout-Fehler nicht als Produkt-/Docker-Fehler.
• Wenn der Kandidat rebasiert wird oder sich sein Basis-SHA nach dem Warmstart ändert, stoppen Sie die task-eigene Box und wärmen Sie eine frische auf, bevor Sie testen. Die Testbox-Quellensynchronisierung ist relativ zum gewärmten Quellbaum; eine Fortsetzung kann eine alte Basisddatei mit einem neuen Kandidaten-Diff vermischen und falsche Lockfile- oder Docker-Fehler erzeugen.
• Wiederverwendete Testboxen werden nach ihrem ersten erfolgreichen Lauf gegen ihre aufgezeichnete Quelle geprüft. Nur-Quell-Änderungen dürfen den Lease wiederverwenden; Basis-, Abhängigkeits-, Wrapper- oder Testbox-Workflow-Drift erfordert einen neuen Lease. Setzen Sie OPENCLAW_TESTBOX_ALLOW_STALE=1 nicht für Release-Nachweise.
• Führen Sie für einen festgelegten Release-Kandidaten mit dem unterstützten Kapsel-bewussten Wrapper node scripts/crabbox-wrapper.mjs run --blacksmith-ref main -- <command> von diesem Kandidaten-Checkout aus, wenn Sie Testbox verwenden. Die Kapsel bewahrt Kandidaten-Quelle und eingefrorene Abhängigkeiten, während main aktuelle Zulassungslimits liefert. Wenn dem Kandidaten dieser Wrapper-Vertrag fehlt, verwenden Sie die exakte Ziel-Release-Validierungsroute unten mit separaten Validierungs- und Tooling-SHAs. Lösen Sie keine Kandidaten-Testbox-Workflow-Refs aus.

…

Publikationsanforderungen

• FRV muss unter dem festgelegten P's eingecheckter Verzichtserklärung erfolgreich abschließen, alle erforderlichen Lanes müssen bestehen. Stabile Tags erfordern stabile/full-Nachweise, Soak und blockierende Leistung.

Beobachten

Verwenden Sie pnpm frv watch --run <parent-run-id>, um einen Eltern-Lauf zu beobachten. Es werden Logs nur für fehlgeschlagene oder blockierende Jobs abgerufen, um REST-Kontingent zu sparen.