OpenClaw-Release-CI

OpenClaw Release CI

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

Leitplanken

• Kein Versionssprung, Tag, npm-Publish, GitHub-Release oder Release-Promotion ohne explizite Zustimmung des Operators.
• Überprüfe Provider-Geheimnisse, bevor teure vollständige Release-Matrizen ausgelöst werden.
• Setze keine GitHub-Geheimnisse aus unvalidierten 1Password-Kandidaten. Wenn ein Kandidat 401/403 zurückgibt, lasse das bestehende Geheimnis unverändert und melde den genauen fehlenden Provider.
• Verwende $one-password für Lese-/Schreibzugriffe auf Geheimnisse: eine persistente tmux-Sitzung, nur gezielte Elemente, keine Ausgabe von Geheimnissen.
• Beobachte einen übergeordneten Lauf plus kompakte Zusammenfassungen der untergeordneten Läufe. Vermeide breite gh run view-Polling-Schleifen; REST-Kontingent ist schnell aufgebraucht.
• Rufe Logs nur für fehlgeschlagene oder aktuell blockierende Jobs ab. Wenn das Kontingent niedrig ist, höre mit dem Polling auf und warte auf den Reset.
• Behandle Live-Provider-Flatterfehler getrennt von Codefehlern: beweise die Gültigkeit des Schlüssels, den HTTP-Status des Providers, Wiederholungsnachweise und die genaue fehlschlagende Spur, bevor du Code bearbeitest.

Preflight

Vor der vollständigen Release-Validierung:

node .agents/skills/openclaw-release-ci/scripts/verify-provider-secrets.mjs --required openai,anthropic,fireworks
gh api rate_limit --jq '.resources.core'
git status --short --branch
git rev-parse HEAD

1Password-Servicekonto-Werte sind die erste Quelle für den Release-Provider-Preflight. Injiziere zuerst diese genauen gezielten Schlüssel und führe dann den Verifizierer aus; verwende die Umgebungsvariable nur, wenn sie bereits absichtlich für diesen Release injiziert wurde. Das Skript gibt nur den Provider-Status und die HTTP-Klasse aus, niemals Tokens.

Dispatch

Bevorzuge den vertrauenswürdigen Workflow auf main und ziele auf den genauen Release-SHA:

gh workflow run full-release-validation.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f ref=<release-sha> \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f rerun_group=all

Verwende release_profile=stable, es sei denn, der Operator verlangt ausdrücklich die breite Matrix aus beratenden Providern/Medien. Verwende nach gezielten Korrekturen eine enge rerun_group.

Watch

Verwende den Zusammenfassungs-Helfer anstelle von wiederholtem rohem Polling:

node .agents/skills/openclaw-release-ci/scripts/release-ci-summary.mjs <full-release-run-id>

Dann schaue nur zu, wenn es nützlich ist:

gh run watch <full-release-run-id> --repo openclaw/openclaw --exit-status

Stoppe die Beobachter, bevor du die Runde beendest oder die Strategie wechselst.

Fehlerbehebung

1. Bestätige den übergeordneten SHA und die IDs der untergeordneten Läufe.
2. Liste nur die fehlgeschlagenen Jobs auf:

   gh run view <child-run-id> --repo openclaw/openclaw --json jobs \
     --jq '.jobs[] | select(.conclusion=="failure" or .conclusion=="timed_out" or .conclusion=="cancelled") | [.databaseId,.name,.conclusion,.url] | @tsv'
   

3. Rufe das Log eines fehlgeschlagenen Jobs ab. Wenn das Rate-Limit erreicht ist, notiere die Reset-Zeit und vermeide weitere REST-Aufrufe.
4. Bei geheimnisaussehenden Fehlern validiere den Provider-Endpunkt von derselben Geheimnisquelle, bevor du Code bearbeitest.
5. Bei Live-Cache-Fehlern untersuche, ob es sich um einen fehlenden/ungültigen Schlüssel, leeren Text, Provider-Ablehnung, Timeout oder Basislinien-Fehlschlag handelt. Schwäche keine Release-Gates ohne klaren Provider-Nachweis.
6. Korrigiere gezielt, führe lokale/geänderte Beweise aus, committe, pushe und starte die kleinste passende Gruppe erneut.

Nachweise

Erfasse:

• Release-SHA
• URL des vollständigen übergeordneten Laufs
• IDs der untergeordneten Läufe und Ergebnisse: CI, Release Checks, Plugin Prerelease, NPM Telegram
• gezielte lokale Beweisbefehle
• Ergebnis des Provider-Secret-Preflights
• bekannte Lücken oder nicht zusammenhängende Fehler

Für Lektionen und Wiederherstellungsmuster lies references/release-ci-notes.md.