release-openclaw-nightly

Nightly-Release

Wird für die Alpha-/Nightly-Release-Automatisierung von Tideclaw/OpenClaw verwendet, manuelle Alpha-Auslöser, Beta-Vorbereitung, Reparatur von Release-Branches und Vorwärtsportierung nach dem Release. Lade $release-private, falls vorhanden, bevor Tideclaw-Host-Pfade, Cron-IDs oder Discord-Routing-IDs verwendet werden.

Richtlinie

• Alpha-/Nightly-Läufe alle 12 Stunden oder durch manuellen Auslöser.
• Beta wird von Discord aus manuell von einem bewährten Alpha-/Release-Branch ausgelöst.
• Stable/Latest benötigt immer eine explizite menschliche Bestätigung.
• Niemals von einem unreinen Checkout oder direkt von main aus veröffentlichen.
• Main kann beschäftigt oder defekt sein; Alpha-Arbeiten müssen isoliert sein, damit vorübergehende Main-Fehler kein nutzbares Nightly blockieren.
• Nur veröffentlichen, wenn der Release-Branch-Nachweis grün ist.
• Nach einem erfolgreichen Alpha die Commits des Release-Branches zurück in main portieren und die Main-CI auf Grün prüfen.
• Vorwärtsportierungs-PRs enthalten nur wiederverwendbare Fixes, die benötigt werden, um die Nightly-/Release-Checks zu bestehen. Sie dürfen keine Alpha-Versionssprünge, Versionshinweise, Changelog-Release-Einträge, Tags, generierte Artefakte oder Statusdatei-Updates enthalten.
• Nur Alpha-/Nightly-Branches der letzten 3 Tage behalten, plus alle Branches mit einem aktiven Lauf, offenem PR oder Release-Tag.
• Niemals breite Env-/Token-Dumps durchführen. Für GitHub-Schreibzugriffe auf dem Tideclaw-Host den folgenden Tideclaw gh-Schreibwrapper verwenden.

Identität

Tideclaw sollte unter seiner eigenen Maschinenidentität auf Release-Branches und Vorwärtsportierungs-Branches committen:

git config user.name "Tideclaw"
git config user.email "[email protected]"

Dies ist gut für die Überprüfbarkeit, wenn Commits eindeutig maschinengeschrieben und von CI abgesichert sind. Vermeide direkte Pushes zu geschütztem main; Vorwärtsportierung per PR/Automerge, es sei denn, die Repository-Richtlinie erlaubt explizit, dass der Bot nach grünen Prüfungen pushen kann. Füge menschliche Co-authored-by nur hinzu, wenn ein Mensch den Patch oder expliziten Commit-Text geliefert hat.

Branch-Struktur

• Branch-Präfix: tideclaw/alpha/
• Branch-Name: tideclaw/alpha/YYYY-MM-DD-HHMMZ
• Basis: aktueller origin/main-SHA zum Zeitpunkt der Auslösung.
• Statusdatei: Auflösen aus $release-private auf dem Tideclaw-Host.
• Release-Tag: vYYYY.M.PATCH-alpha.N
• npm-dist-tag: alpha

PATCH ist eine sequenzielle monatliche Release-Train-Nummer, niemals der Kalendertag. Bestimme den Alpha-Train aus Stable- und Beta-Releases; ignoriere reine Alpha-Patch-Nummern bei der Wahl des nächsten Trains. Verwende eine Nummer größer als den höchsten Stable-/Beta-Patch für den Monat, erhöhe dann nur alpha.N für wiederholte Nightlies auf diesem Train. Wenn ein Beta auf diesem nächsten Patch existiert, verschiebe Alpha auf den folgenden Train. Legacy-reine Alpha-Tags mit überhöhten Patch-Nummern erweitern nicht die Beta-/Stable-Nummerierung.

Alte Alpha-Branches nicht für einen neuen Lauf wiederverwenden. Bei erneutem Ausführen desselben Basis-SHA einen neuen zeitgestempelten Branch erstellen und den Grund aufzeichnen.

Start

1. Arbeite im Tideclaw-Host-Checkout aus $release-private.
2. Zuerst fetchen:

git fetch origin main --tags --prune
git switch main
git merge --ff-only origin/main
BASE_SHA="$(git rev-parse origin/main)"
BRANCH="tideclaw/alpha/$(date -u +%Y-%m-%d-%H%MZ)"
git switch -c "$BRANCH" "$BASE_SHA"

3. Release-Dokumente/Skripte des Repositorys lesen, bevor etwas geändert wird:
   • AGENTS.md
   • Release-Dokumente unter docs/
   • Release-Skripte unter scripts/
   • .github/workflows/*release*
4. $BASE_SHA mit dem letzten erfolgreichen Alpha-Status und aktuellen Git/npm/GitHub-Alpha-Tags vergleichen. Wenn bereits veröffentlicht, Überspringen melden und nicht veröffentlichen.

Manueller Auslöser:

CRON_ID="<from release-private>"
OPENCLAW_ALLOW_ROOT=1 openclaw cron run "$CRON_ID" --expect-final --timeout 21600000

Discord-Alpha-Auslöser

Tideclaw kann Alpha sofort von Discord aus ausführen, wenn ein Maintainer Tideclaw in #releases oder #maintainers erwähnt.

Akzeptierte Formen:

@Tideclaw run alpha now
@Tideclaw alpha release from main now
@Tideclaw trigger alpha

Regeln:

1. Dies als manuellen Alpha-Auslöser behandeln, gleichwertig zum Alpha-Cron-Job.
2. Vom aktuellen origin/main starten und einen frischen tideclaw/alpha/YYYY-MM-DD-HHMMZ-Branch erstellen.
3. Dem normalen Alpha-Workflow folgen: vorherige Fixes wiederverwenden, lokale Prüfungen durchführen, auf dem Alpha-Branch fixen, Release-CI ausführen, Alpha nach grünen Gates veröffentlichen, dann wiederverwendbare Fixes per Fixes-Only-PR vorwärtsportieren.
4. Wenn ein anderer Alpha-/Beta-/Stable-Release-Lauf bereits aktiv ist, den aktiven Branch/Lauf melden und stoppen.
5. Der #maintainers-Auslöser erfordert eine explizite Tideclaw-Erwähnung; nicht auf unerwähnte Release-Chats dort reagieren.
6. Discord-Rollen-/Benutzer-IDs und Live-Host-Hotfix-Notizen aus $release-private auflösen.

Discord-Beta-Auslöser

Tideclaw kann Beta-Releases von #releases oder erwähnten #maintainers-Befehlen nur ausführen, wenn ein Maintainer einen expliziten Beta-Auslöser sendet. Dies als menschliche Genehmigung für Beta behandeln, nicht für Stable/Latest.

Akzeptierte Formen:

@Tideclaw beta release from vYYYY.M.PATCH-alpha.N
@Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ
@Tideclaw beta release from latest proven alpha

Regeln:

1. Die Wörter beta release und ein Quell-Alpha-Tag/-Branch oder latest proven alpha erfordern.
2. Wenn die Quelle mehrdeutig ist, eine klärende Frage in #releases stellen und stoppen.
3. Die Quell-Alpha zuerst verifizieren: GitHub-Release, npm alpha-Paket, Release-CI, aufgezeichnete Statusdatei und Branch-/Tag-SHA.
4. Einen frischen Beta-Branch tideclaw/beta/YYYY-MM-DD-HHMMZ von der bewährten Alpha-Quelle erstellen, nicht direkt von einem sich bewegenden main.
5. Nur Stabilisierungsfixes wiederverwenden/squashen, die bereits auf Alpha bewährt sind. Keine unrelated Alpha-Release-Mechaniken importieren, es sei denn, die Beta-Release-Dokumente erfordern sie.
6. Beta als vYYYY.M.PATCH-beta.N berechnen, passend zu npm --tag beta. Reine Alpha-Patch-Nummern bei der Auswahl des Beta-Trains ignorieren.
7. Beta-Release-Validierung/Preflight/Full-Release-CI ausführen und Fehler auf dem Beta-Branch beheben.
8. Beta nur nach grünen Beta-Gates veröffentlichen. GitHub Actions/OIDC verwenden, niemals direkte npm-Veröffentlichung vom Host.
9. Die finale Discord-Zusammenfassung muss Quell-Alpha, Beta-Tag/Version, Branch, Fix-Commits, Workflow-Run-IDs, npm/GitHub-Nachweis und jeden übersprungenen/blockierten Grund enthalten.
10. Nach der Beta-Veröffentlichung wiederverwendbare Fixes nach main portieren, unter Verwendung derselben Fixes-Only-PR-Regeln unten.

Vorherige Fixes wiederverwenden

Vor der Ausführung von Prüfungen kürzliche Tideclaw-Alpha-Branches nach Fixes durchsuchen, die während früherer Release-Versuche gemacht wurden:

1. Die Tideclaw-Statusdatei aus $release-private für den letzten erfolgreichen Alpha-Branch und Fix-Commit-SHAs lesen.
2. Kürzliche Remote-Branches auflisten:

git for-each-ref refs/remotes/origin/tideclaw/alpha --format='%(refname:short) %(committerdate:iso-strict)'

3. Nur Tideclaw-Alpha-Branches der letzten 3 Tage plus den letzten erfolgreichen Alpha-Branch berücksichtigen.
4. Für jeden Kandidaten-Branch Commits inspizieren, die nicht im aktuellen origin/main sind:

git log --no-merges --reverse --format='%H%x09%s' origin/main..origin/tideclaw/alpha/YYYY-MM-DD-HHMMZ

5. Nur echte Stabilisierungsfixes cherry-picken, die noch auf den neuen Alpha-Branch anwendbar sind. Bevorzuge Commits, die als fixCommitShas in der Statusdatei aufgezeichnet sind.
6. Versionssprünge, Changelog-Release-Einträge, Tag-Artefakte, generierte Versionshinweise, Statusdatei-Only-Commits und einmalige Debug-Instrumentierung überspringen.
7. Wenn ein Cherry-Pick Konflikte verursacht, prüfen, ob der aktuelle Main bereits einen äquivalenten Fix enthält. Wenn nicht, minimal auflösen und die Commit-Nachricht klar halten.
8. Wiederverwendete Commit-SHAs getrennt von neu verfassten Fix-SHAs im Alpha-Status und in der finalen Discord-Zusammenfassung aufzeichnen.

git cherry, git range-diff und gezielte Test-Wiederholungen verwenden, um Duplikate von Fixes zu vermeiden, die bereits auf main vorhanden sind.

Reparaturschleife

Den Branch als Release-Kandidaten-Reparaturoberfläche verwenden:

1. Zuerst enge lokale Prüfungen durchführen: geänderte Tests, Release-Preflight, Type/Lint/Build-Gates, die von den Release-Dokumenten benötigt werden.
2. Wenn lokale Prüfungen fehlschlagen, auf dem Alpha-Branch mit minimalen Commits beheben.
3. Jeden kohärenten Fix als Tideclaw committen.
4. Die fehlgeschlagene lokale Prüfung nach jedem Fix erneut ausführen.
5. Fehler nicht durch Bearbeiten von Baselines, Expected-Failure-Listen, Ignore-Dateien oder Release-Inventar verstecken, es sei denn, die Release-Dokumente erfordern es explizit und der Diff ist gerechtfertigt.
6. Wenn ein Fehler flaky ist, einmal erneut ausführen; wenn immer noch rot, als echt behandeln.
7. Wenn der Fix eindeutig für main nützlich ist, ihn klein und vorwärtsportierbar halten. Breite Refactorings während der Alpha-Stabilisierung vermeiden.

Commit-Beispiele:

git add <files>
git commit -m "fix: stabilize alpha release preflight"
git push -u origin "$BRANCH"

Release-CI

Nach lokalem Nachweis:

1. Nächstes vYYYY.M.PATCH-alpha.N aus vorhandenen Git-Tags, npm-Versionen und GitHub-Releases berechnen. PATCH aus Stable-/Beta-Trains auswählen, nicht das Datum oder den höchsten Alpha-Only-Patch. Denselben Alpha-Train wiederverwenden und alpha.N erhöhen, bis dieser Patch ein Beta hat; nach einem Beta existiert, den folgenden Patch für neue Alpha-Builds verwenden.
2. Die Paketversion und Release-Metadaten des Alpha-Branches an dieses Tag anpassen, committen und den Branch pushen.
3. Release-Validierung vom Alpha-Branch ausführen, unter Verwendung von GitHub CLI, nicht Browser/Fetch-Tools. Auf dem Tideclaw-Host ist bloßes gh ein schreibgeschützter Codex-Sandbox-Wrapper; /usr/local/bin/gh-tideclaw-write für schreibfähige Befehle wie workflow run, run cancel und Publish-Dispatch verwenden:

GH="/usr/local/bin/gh-tideclaw-write"
SHA="$(git rev-parse HEAD)"
TAG="v$(node -p "require('./package.json').version")"
BRANCH="$(git branch --show-current)"

"$GH" workflow run full-release-validation.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f ref="$BRANCH" \
  -f release_profile=beta \
  -f rerun_group=all

"$GH" workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$SHA" \
  -f preflight_only=true \
  -f npm_dist_tag=alpha

4. Die genauen Workflow-Run-IDs und Head-SHA mit gh run list, gh run view und gh api überwachen. Schreibgeschütztes gh ist in Ordnung für Polling; $GH nur verwenden, wenn ein Befehl GitHub mutiert. Kein Codex-Browser/Fetch für GitHub-API-Polling verwenden; frühere Tideclaw-Läufe sind dort nach erfolgreichem Preflight fehlgeschlagen.
5. Für Alpha sind blockierende Gates diejenigen, die Tideclaw direkt reparieren kann oder die Paketsicherheit nachweisen: normale CI, Plugin-PreRelease, npm-Preflight, Paketvorbereitung, Install-Smoke, Tag/Erreichbarkeit und Veröffentlichungsüberprüfung. Cross-OS, Live-Channel, QA-Lab, Paket-Akzeptanz, langes Docker-E2E und Telegram-Paket-E2E-Fehler als beratend behandeln; in Discord melden und fortsetzen, wenn die blockierenden Gates grün sind.
   • Wenn rerun_group=all nur auf beratenden Spuren hängt, nachdem CI, Plugin-PreRelease, npm-Preflight, Paketvorbereitung und Install-Smoke grün sind, ein fokussiertes Full Release Validation auf demselben Head mit -f rerun_group=install-smoke auslösen. Diesen erfolgreichen fokussierten Full Release Validation-Lauf als Veröffentlichungsnachweis verwenden und die separaten CI/Plugin/Full-Advisory-Run-IDs in die Discord-Zusammenfassung aufnehmen.
6. Wenn ein blockierendes Gate fehlschlägt, auf dem Alpha-Branch fixen, pushen und nur die fehlgeschlagene oder erforderliche Release-CI erneut ausführen. Wenn der Commit sich ändert, alte Preflight/Full-Validation-Run-IDs verwerfen und für den neuen Head erneut ausführen.
7. Nachdem Full Validation und npm-Preflight auf demselben Branch-Head grün sind, das Release-Tag von diesem genauen Commit erstellen und pushen:

git tag -a "$TAG" "$SHA" -m "openclaw ${TAG#v}"
git push origin "$TAG"

8. Den Publish-Wrapper vom selben Alpha-Branch aus auslösen. Die erfolgreiche npm-Preflight-Run-ID und die Full-Release-Validation-Run-ID plus genauen Versuch vom selben Head-SHA verwenden:

FULL_RELEASE_VALIDATION_RUN_ATTEMPT="$(gh api \
  "repos/openclaw/openclaw/actions/runs/${FULL_RELEASE_VALIDATION_RUN_ID}" \
  --jq .run_attempt)"
"$GH" workflow run openclaw-release-publish.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$TAG" \
  -f preflight_run_id="$NPM_PREFLIGHT_RUN_ID" \
  -f full_release_validation_run_id="$FULL_RELEASE_VALIDATION_RUN_ID" \
  -f full_release_validation_run_attempt="$FULL_RELEASE_VALIDATION_RUN_ATTEMPT" \
  -f npm_dist_tag=alpha \
  -f plugin_publish_scope=all-publishable \
  -f publish_openclaw_npm=true \
  -f release_profile=beta \
  -f wait_for_clawhub=false

9. Den Publish-Wrapper plus untergeordnete Läufe überwachen. Wenn openclaw-npm-release.yml auf die npm-release-Umgebung wartet und Tideclaw sie nicht genehmigen kann, dies als einzigen Blocker melden; das Release nicht als abgeschlossen bezeichnen.
10. npm nicht direkt vom Host veröffentlichen; GitHub Actions/OIDC verwenden.

Wichtig: openclaw-npm-release.yml mit preflight_only=true bereitet nur Artefakte vor. Es veröffentlicht nicht. Ein erfolgreiches Alpha erfordert den späteren openclaw-release-publish.yml-Wrapper, einen gepushten Git-Tag, npm alpha-dist-tag-Nachweis und ein GitHub-PreRelease.

Veröffentlichtes Alpha überprüfen

Das Release ist nicht abgeschlossen, bis alles zutrifft:

• GitHub-Tag existiert.
• GitHub-Release existiert und ist als PreRelease markiert.
• Release-Body verlinkt npm-Versionsseite, Registry-Tarball, Integrität und CI/Nachweis.
• npm view openclaw@<version> zeigt die genaue Version, dist-tag alpha, Tarball, Integrität und Veröffentlichungszeit.
• Installierter/Paket-Smoke folgt den Release-Dokumenten des Repositorys.
• Die Tideclaw-Statusdatei aus $release-private zeichnet Version, Tag, Basis-SHA, Branch, Fix-Commit-SHAs, Workflow-Run-IDs, npm-Integrität und Zeitstempel auf.

Finale Discord-Zusammenfassung in #releases:

• Tag/Version
• Basis-SHA
• Branch
• Fix-Commits
• Workflow-Run-IDs
• npm/GitHub-Nachweis
• Übersprungener/blockierter Grund, wenn nicht veröffentlicht

Discord-sichere Markdown-Links mit Winkelklammer-Zielen verwenden. Niemals Geheimnisse ausgeben.

Vorwärtsportierung

Nach einem erfolgreichen Alpha einen Fixes-Only-PR zurück zu main erstellen:

1. Einen Vorwärtsportierungs-Branch vom aktuellen origin/main erstellen/aktualisieren:

git fetch origin main --prune
git switch -c "tideclaw/forward-port/$(date -u +%Y-%m-%d-%H%MZ)" origin/main

2. Nur Release-Branch-Commits cherry-picken, die echte Fixes sind, die benötigt werden, um die Nightly-/Release-Checks zu bestehen.
3. Alpha-Versionssprünge, Changelog-Release-Einträge, Versionshinweise, Tag-Artefakte, generierte Release-Assets, Statusdatei-Only-Commits und jeden Commit ausschließen, dessen einziger Zweck die Veröffentlichung des Alpha war.
4. Wenn ein Commit einen echten Fix mit Release-/Versionsänderungen mischt, ihn aufteilen: nur die Fix-Hunks in eine neue Nachricht auf dem Vorwärtsportierungs-Branch wiedergeben.
5. Die Konfliktauflösung mit einem neuen, nicht gemischten Commit-Text festhalten.
6. Titel und Text des PRs klar machen, dass es ein Fixes-Only-PR ist:

title: "fix: port alpha release fixes [skip changelog]"
body: |
  Voorwärtsportierung von Fixes aus dem Alpha-Branch tideclaw/alpha/YYYY-MM-DD-HHMMZ, die erforderlich sind, um die Nightly- und Release-Prüfungen zu bestehen. Enthält keine Alpha-Versionssprünge, Changelog-Einträge oder Release-Artefakte. Details zum Alpha-Release finden sich im Alpha-Branch und der Discord-Zusammenfassung.

  $TAG

7. Den PR öffnen, CI bestätigen und wenn CI grün ist, mit automatischem Merge fortfahren, es sei denn, die Repository-Richtlinie erfordert eine explizite menschliche Überprüfung.
8. Wenn der PR Merge-Konflikte hat, sie auf dem Vorwärtsportierungs-Branch beheben, pushen und erneut öffnen.
9. Wenn der PR nur aus Pegel-Fixes (z. B. snapshot version bumps, CI-Pfad-Updates) besteht, die nicht auf main benötigt werden, den gesamten PR abbrechen und einen Kommentar hinterlassen, warum.
10. Den erfolgreich gemergten Vorwärtsportierungs-Status in der Tideclaw-Statusdatei aufzeichnen.

Branch-Aufräumung

Nachdem alle Alpha-, Beta- und Vorwärtsportierungs-Workflows für diesen Release-Zyklus abgeschlossen sind:

1. Remote-Refs auflisten:

git for-each-ref refs/remotes/origin/tideclaw --format='%(refname:short)'

2. Nur Tideclaw-Branches berücksichtigen.
3. Löschkandidaten:
   • Tideclaw-Branches ohne Aktivität in den letzten 3 Tagen.
   • Alpha-/Beta-Branches ohne aktiven CI-Lauf, offenen PR, Release-Tag oder Pending-Validierung.
4. Nie löschen:
   • Den Branch, auf dem Tideclaw gerade arbeitet.
   • Einen Branch mit einem aktiven CI-Lauf, offenen PR oder Release-Tag.
   • Den letzten erfolgreichen Alpha-/Beta-Branch (aufgezeichnet in der Statusdatei).
5. Branches mit git push origin --delete <branch> entfernen.
6. Nach der Aufräumung git fetch origin --prune ausführen.
7. Gelöschte Branches und Gründe in der Tideclaw-Statusdatei und in der Discord-Zusammenfassung aufzeichnen.

Eigenschafts-/Konfigurationsverzeichnis

Die folgenden Eigenschaften aus $release-private auflösen:

• CRON_ID – Cron-Job-ID für den Alpha-Lauf.
• Discord-Kanal-ID für #releases
• Discord-Kanal-ID für #maintainers
• Discord-Rollen-ID für maintainer
• Discord-Benutzer-ID des primären Tideclaw-Hosts
• Pfad zum gh-tideclaw-write-Wrapper: immer /usr/local/bin/gh-tideclaw-write
• Pfad zum Tideclaw-Host-Checkout (Stammverzeichnis des Repositorys)
• Pfad zur Tideclaw-Statusdatei (JSON in $release-private)
• Live-Host-Änderungsnotizen/Overrides

Optionale Modi

• --skip-ci – Nur Preflight/Validierung, nichts veröffentlichen.
• --force – Auslöser trotz aktivem Lauf (nur für manuelle Notfälle; überschreibt Regel 4 des Discord-Alpha-Auslösers).
• --dry-run – Statusdatei und Discord simulieren, aber keine Git-Pushes, CI-Auslöser oder Veröffentlichungen.

Gemeinsame Fehlerbehebungen

Fehler: gh-Befehl nicht gefunden oder schreibgeschützt – /usr/local/bin/gh-tideclaw-write für schreibende GitHub-Operationen verwenden. Vorhandensein und Ausführbarkeit überprüfen; den Host-Betreuer kontaktieren, falls fehlend.

Fehler: Cherry-Pick-Konflikt – git diff mit dem Ziel-Branch ausführen, um zu sehen, ob der Fix bereits vorhanden ist. Wenn nicht, minimal mit klarer Commit-Nachricht auflösen.

Fehler: NPM-Preflight schlägt fehl – Paketversion, Abhängigkeiten und Konfiguration überprüfen. Nicht umgehen; auf dem Release-Branch fixen.

Fehler: CI-Workflow nicht gefunden – Workflow-Dateinamen und Trigger-Ereignisse mit .github/workflows/ abgleichen. Branch-Namen korrigieren, falls nötig.

Fehler: Discord-Auslöser von falschem Benutzer/Kanal – Nur auf erwähnte Befehle in #releases und #maintainers reagieren. Rolle/Benutzer aus $release-private überprüfen.

Fehler: Abgelaufener GitHub-Token – Token im Host-Setup erneuern. Der gh-tideclaw-write-Wrapper verwendet OIDC, sodass der Token auf dem Host möglicherweise nicht benötigt wird; Token-Ablauf nur für Cron-basierte Auslöser prüfen.