OpenClaw リリース CI
$release-openclaw-maintainer と $openclaw-testing とともに使用します。リリース候補の完全な検証、インストール/アップデートの証明、ライブプロバイダーチェック、またはCIの復旧が必要な場合に利用します。
ガードレール
- 明示的なオペレーターの承認なしに、バージョンアップ、タグ作成、npm公開、GitHubリリース、リリース昇格を行わないでください。
- コンパクション、再開、または新しいステアリングの後は、最新の明示的なオペレーター指示から実効目標と現在のフェーズを書き換えてください。古いスコープをアクティブなリリースにマージしないでください。
- リリースブランチまたはCode SHAが存在する場合は、リリーススコープを固定してください。その正確なリリースを検証して出荷してください。移動する
mainを第二のワークキューにしないでください。 - C（候補）、Q（テスト資格）、P（許可/集約/検証者/公開者）、再実行グループ、プロファイル、実効ソーク、コンテキスト/トランスポート参照 を記録してください。新しい候補テストの資格はデフォルトで Q=C となり、完全なワークフロー、再利用可能なワークフロー、ローカルアクション、スクリプト、プランナー、コントラクト、カバレッジのクロージャを含みます。Code SHAとRelease SHAはライフサイクルの役割を維持し、追加のワークフローIDとしては扱いません。
- 候補ヘルパーは、存在しないリリースタグ、または候補SHAと正確に一致する既存の軽量タグまたは注釈タグを受け入れます。競合するタグまたはリモートルックアップの失敗は検証を停止します。タグを移動して復旧しようとしないでください。
- C/Q を凍結し、main または保護された公開タグ上で信頼できるPを独立して選択してください。C/Q は P の祖先である必要はありません。欠落している候補コントラクトは意図的なバックポートが必要です。新しい main ツールを黙って代用しないでください。
- Code SHA が凍結された後、リリースファイアブレイクを適用してください。確認された製品欠陥、誤ったまたは検証不可能なパッケージバイト、セキュリティ欠陥、または公開を不可能にする障害のみを許可します。その他の発見事項は、公開後の信頼性向上または次のベータ版のためにキューに入れてください。依存関係の勧告はファイアブレイクの対象外です。リリース証拠として記録し、公開後に main でバンプをキューに入れてください。既知のマルウェアのみが公開を停止します。
- 凍結されたCI子ジョブは、QのNodeシャードプランナーと測定されたコストを使用しますが、候補チェックアウトからテストを発見して実行します。ホストされたフルリリースプランは、12分を超える測定行を分割します。ファイルカバレッジ、ワーカー制限、完全なタイミング生成を保持してください。分割できない予算超過の所有者は、リリース予算を増やすのではなく分割する必要があります。子ジョブの完了後、クローズアウトはその正確な実行に対して
scripts/ci-shard-timings-refresh.mtsを実行し、生成されたコストをコミットします。測定値を手動編集しないでください。 - 候補テストは自身の凍結されたQクロージャを実行します。許可されたPはFRVの集約決定とチェックインされたwaiverポリシーを所有します。mainのみのチェックと将来のmainシナリオは、暗黙のリリース要件ではありません。凍結された資格ハーネスを修正するには、新しいC/Qと新たにバインドされた証拠が必要です。Pのみの許可/集約/検証者/公開者の修復は、C/Qとその元の証拠を保持できます。
- 保護された軽量
release-publish/<12sha>-<provenance-run>タグは、QではなくPを識別します。サフィックスはタグ作成の来歴を記録し、現在の親ではありません。公開ヘルパーは--workflow-sha <P>引数を保持します。FRVヘルパーの--workflow-shaは代わりにQを選択し、候補ルートではCと等しくなければなりません。 - オペレーターが要求した変更、またはこのリリースを妨げる最小のクリティカルなmain所有ブロッカー（リリースブランチから処理できないもの）のためにのみ
mainにタッチしてください。MainのCI健全性はリリースをゲートしません。リリースツーリングのランディングが、それが原因ではない main の障害によってブロックされた場合は、クリーンな main チェックアウトでその障害が既に存在することを証明し、PR本文に記録してマージします。アクティブなリリース中は、その正確なケースについて管理者マージが許可されます。別のレーンがリリースのクリティカルパスから外れて、並行して赤い main を修正します。 - ツーリングのみの修正は、プッシュ前に
release-fast-laneラベルを追加して main にランディングします（Release tooling fast lane 参照）。openclaw/ci-gateはリント、タイプ、ガード、依存関係、ドキュメント、および変更されたNode行のみを実行します。ネイティブメンテナーワークフロー を通じてランディングしてください。そのワークフローはレビューとランディング要件（アドバイザリClawSweeperポリシーを含む）を所有します。ラベルはCI選択のみを変更します。 OPENCLAW_RELEASE_RUNNER_GROUPは、オプションで検証の親とワーカー、およびリリース公開の親とその公開子ジョブを、ラベルを変更せずに予約容量にルーティングします。クレデンシャル付きの公開および承認ジョブはデフォルトのGitHubホストラベルに残ります。最初に適格なランナーとリポジトリアクセスを設定してください。未設定の場合は通常のルーティングを維持します。共有ワーカーは呼び出し元のグループを継承します。PR/main CI および関連のないスケジュールジョブはその範囲外です。- 新しい main 検証をディスパッチする前に、夜間の親でCode SHAを確認してください。これは、入力が一致する場合に正確なターゲットディスパッチが採用する子ごとのレシートを封印します。夜間の実行はこの明示的な信頼mainヘルパールート（
--sha <main-sha> --workflow-sha <main-sha> --trusted-workflow-ref main）を使用するため、その親はrelease-ci/<sha12>-<id>ブランチで実行され、mainでは実行されません。 - FRV は、固定されたPのチェックインされたwaiverポリシーの下で成功を結論付ける必要があります。その他の必須レーンはすべて合格する必要があります。Publication requirements を参照してください。安定版タグには安定版/完全な証拠、ソーク、およびブロッキングパフォーマンスが必要です。ベータプロファイルの証拠は安定版の資格を与えることはできません。ソークとパフォーマンスは免除できません。全グループの資格には、9つのLinux/Windows/macOS Gatewayインストール/アップグレードの組み合わせすべてが必要です。最初の失敗、ID、および完全な証拠を保持してください。
- ネイティブのmacOS、Windows、Linux、およびAndroidの公開は、npm/ClawHub、GitHub最終化、およびmainクローズアウトとは独立しています。各プラットフォームは独自の署名、資格、アーティファクト、およびアップデータ要件を保持します。保留中のプラットフォームを正確に報告し、ネイティブのみの障害を並行して修復してください。
- 未検証の1Password候補からGitHubシークレットを設定しないでください。候補が401/403を返した場合は、既存のシークレットをそのままにして、正確な欠落プロバイダーを報告してください。
- シークレットの読み取り/書き込みには
$one-passwordを使用します。1つの永続的なtmuxセッション、対象アイテムのみ、シークレット出力なし。 pnpm frv watch --run <parent>で1つの親実行を監視します（Watch 参照）。広範なgh run viewポーリングループは避けてください。RESTクォータを消費しやすいです。- 失敗した、または現在ブロックしているジョブのログのみをフェッチしてください。クォータが少ない場合は、ポーリングを停止してリセットを待ちます。
- ライブプロバイダーのフレークはコード障害とは別に扱います。キーの有効性、プロバイダーのHTTPステータス、再試行の証拠、およびコードを編集する前に正確に失敗したレーンを証明してください。
- ライブプロバイダーの障害を診断する場合、モデルリスト応答は認証を証明しますが、課金や推論の権利は証明しません。実際のコンプリーションプローブで資格情報を確認してから、有効として扱ってください。最初に資格情報を修正してください。リリース資格情報の失敗を回避するためだけに、代替の認証パスを追加しないでください。
- フルリリース検証は、正確な子ディスパッチ、リリース決定、および診断ドレインを分離します。
fail_fast=falseの場合、子キャンセル呼び出しはゼロです。診断ドレインは、コレクター自体がキャンセルされるかGitHub APIアクセスを失わない限り、選択されたすべての子が終了するまでフォローします。fail_fast=trueの場合、リリース決定はブロッキング障害を所有する正確にアクティブな子のみをキャンセルできます。 - 同じ親の継続には、元のルートが
fail_fast=falseでディスパッチされている必要があります。コントローラーは、再実行の変更の前にその正確なログ入力された設定を検証します。 - 自身の封印された候補アーティファクトを生成した親は継続できません。GitHubの再実行により、それらの以前の試行のアーティファクトが利用できなくなります。候補と資格のSHAを凍結したまま、その親を破棄し、新しい全グループのフルリリース検証を開始してください。
- ディスパッチ後、1つの不変の実行計画アーティファクトが、元の親試行、正確な子タプルとタイトル、選択されたカバレッジ、ゲート、および再利用IDを記録します。同じバイトが正確な実行IDキャッシュキーの下に保存されます。決定、ドレイン、マニフェスト書き込み、証拠検証、および最終検証は、現在の試行のためにそのアーティファクトを消費します。コレクターの再試行はキャッシュされた計画を復元し、検証し、そのアーティファクトを再アップロードし、同じ子を採用します。計画状態の欠落は、計画を再構築したり再ディスパッチしたりする許可ではなく、オーケストレーションの失敗です。
- 再利用された証拠は、計画の封印によって発見されたからといって信頼されるわけではありません。リリース決定は、封印されたターゲットSHA、証拠SHA、ポリシー、変更されたパス、選択された実行、ルート実行、ソースマニフェスト、信頼されたツーリングID、および正確な子チェックを
passedを返す前に繰り返します。 - 親の再試行は、新しい決定とドレインのアーティファクトを独立して選択します。両方とも、ソース試行が異なっていても、同じ不変の計画にバインドする必要があります。
- 子の再試行は、子の実行ID、ワークフローパス、ref、Q SHA、ディスパッチタイトル、イベント、ターゲット、候補、および検証入力が正確に同じままである場合にのみ、同じ不変の計画の一部です。新しい子の試行は一致するジョブを置き換えます。新しい試行に存在しないジョブは引き継がれます。重複したジョブID、欠落した試行、後退した試行、または変更されたタプルはfail closedします。
frv statusとcontinueは、GitHubが最新の再試行で一時的に重複ジョブを返す場合、最大60秒の読み取り専用調整を許可します。実行タプルと試行は固定されたままです。永続的な重複と古い試行の競合はエラーのままです。 - 試行を認識した復旧には
pnpm frv status|watch|rerun --job|rerun --child|continue --failed|verifyを使用してください。コントローラーはステートレスです。不変の実行計画、正確なGitHub実行試行、診断ドレイン、および最終マニフェストのみが権威です。タグ、パッケージ、レジストリエントリ、リリース候補、または公開を書き込むことはありません。 - マージ後のコントローラープルーフは、保護された
main上のレビュー済みランドSHAを、非リリースのFRV Proof BrokerおよびFRV Proof Fixtureを通じて使用する必要があります。マージされたプルリクエスト番号と正確なランドコミットを使用してブローカーをディスパッチしてください。ブローカーは、そのプルリクエストのマージコミットがランドコミットと一致すること、ランドコミットがその信頼されたワークフローSHAと同一またはその祖先であることを証明し、フィクスチャを再実行する直前に権限、マージ、および祖先チェックを繰り返す必要があります。意図的な試行1の失敗から試行2の合格に進むために、正確に固定されたno-opフィクスチャ実行を要求してください。ブローカーは、リリース候補、リリースアーティファクト、公開、リポジトリ参照、置換親、またはその他のワークフローの変更を作成せずに、そのレシートを発行する必要があります。これはホストされたGitHubターゲットジョブ再実行のプルーフです。フォーカスされたコントローラーテストは、不変計画の適格性、グリーン試行の保持、同じ親の収集、および厳密な検証者の呼び出しを所有します。このプルーフに実際のフルリリース検証実行を決して使用しないでください。Full Release Validation を参照してください。 - 1つのリリースオペレーター、1つの
frv watch、および現在の失敗サーフェスに対して最大1つの調査担当者を使用してください。単一のワークフロー遷移を中心に監査-レビュー-計画ツリーを構築しないでください。 - 通常のベータ/安定版リリースでは、Code SHAに最終ノートが既に含まれ、Release SHAとして機能する場合があります。1つの成功した新しいフル親が、両方の役割とその正確な公開バイトを資格付けることができます。その後にノートが変更された場合、後のRelease SHAは、Code SHAからの完全なデルタが選択された
CHANGELOG/YYYY.M.PATCH.mdおよびオプションでCHANGELOG.mdとCHANGELOG/records/YYYY.M.PATCH.mdを変更し、他のパス、名前変更、または削除がない場合にのみ、製品証拠を再利用できます。変更されたバイトは依然として資格が必要です。 - Extended-stableは1つの正確なブランチチップを検証します。通常のCode-SHA/Release-SHA証拠モデルを再利用しません。
- スパースワークツリーまたはTestboxソース同期では、最初に
package.json、pnpm-lock.yaml、および選択されたチェックが読み取るすべてのソースパスを確認してください。いずれかが欠落している場合、そのチェックアウトはリリース依存関係またはDockerレーンを検証できません。停止して、リポジトリリモート変更ゲートまたはフルタスクワークツリーを使用してください。入力が存在し、リリース修正がpackage.jsonまたはpnpm-lock.yamlを変更する場合は、CI=true pnpm install --frozen-lockfileでタスク所有の使い捨てボックスのみを再構築し、Dockerまたはフォーカスされたテストの前に明示的なrequire.resolve()プローブを実行してください。CIフラグにより、pnpmは対話的な確認なしにプリウォームされたモジュールディレクトリを再作成できます。ロックファイルを弱めたり、スパースチェックアウトの失敗を製品/Dockerの失敗としてラベル付けしたりしないでください。 - ウォームアップ後に候補がリベースされたり、そのベースSHAが変更されたりした場合は、タスク所有のボックスを停止し、テスト前に新しいボックスをウォームアップしてください。Testboxソース同期はウォームされたソースツリーに対して相対的です。継続すると、古いベースファイルと新しい候補差分が混ざり、誤ったロックファイルまたはDockerの失敗を引き起こす可能性があります。
- 再利用されたTestboxは、最初の成功実行後に記録されたソースに対してチェックされます。ソースのみの編集はリースを再利用できます。ベース、依存関係、ラッパー、またはTestboxワークフローのドリフトは新しいリースが必要です。リリース証拠のために
OPENCLAWF_TESTBOX_ALLOW_STALE=1を設定しないでください。 - コミットされたリリース候補で、サポートされているカプセル対応ラッパーがある場合は、その候補のチェックアウトから
node scripts/crabbox-wrapper.mjs run --blacksmith-ref main -- <command>を実行し、Testboxを使用します。カプセルは候補ソースと凍結された依存関係を保持し、mainは現在の許可制限を提供します。候補にそのラッパーコントラクトがない場合は、以下の正確なターゲットリリース検証ルートを、別の検証とツーリングSHAとともに使用してください。候補Testboxワークフロー参照をディスパッチしないでください。
[truncated for translation]