OpenClaw リリース CI
リリース候補に完全なバリデーション、インストール/アップデート証明、ライブプロバイダーチェック、またはCI復旧が必要な場合に、$openclaw-release-maintainer と $openclaw-testing と共に使用します。
ガードレール
- 明示的なオペレーターの承認なしに、バージョンアップ、タグ付け、npm公開、GitHubリリース、またはリリースプロモーションを行わないでください。
- 高価なフルリリースマトリックスをディスパッチする前に、プロバイダーシークレットを検証してください。
- 未検証の1Password候補からGitHubシークレットを設定しないでください。候補が401/403を返した場合は、既存のシークレットはそのままにして、正確な不足プロバイダーを報告してください。
- シークレットの読み取り/書き込みには
$one-passwordを使用してください。1つの永続的なtmuxセッション、対象のアイテムのみ、シークレット出力は禁止です。 - 1つの親実行とコンパクトな子要約を監視します。広範な
gh run viewポーリングループは避けてください。RESTクォータを簡単に消費します。 - ログは失敗したジョブまたは現在ブロックしているジョブに対してのみ取得してください。クォータが少ない場合はポーリングを停止し、リセットを待ちます。
- ライブプロバイダーのフレークはコード障害とは別に扱います。コードを編集する前に、キーの有効性、プロバイダーのHTTPステータス、再試行の証拠、および正確な失敗レーンを証明してください。
事前確認
完全なリリースバリデーションの前に:
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サービスアカウントの値が、リリースプロバイダーの事前確認の最初のソースです。最初にそれらの正確な対象キーを注入し、次に検証ツールを実行します。周囲の環境変数は、このリリースのために既に意図的に注入されている場合にのみ使用します。スクリプトはプロバイダーステータスとHTTPクラスのみを出力し、トークンは決して出力しません。
ディスパッチ
main の信頼できるワークフローを優先し、正確なリリース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
オペレーターが明示的に広範なアドバイザリプロバイダー/メディアマトリックスを要求しない限り、release_profile=stable を使用してください。フォーカスされた修正後は、狭い rerun_group を使用します。
監視
繰り返しの生のポーリングの代わりに、サマリーヘルパーを使用します:
node .agents/skills/openclaw-release-ci/scripts/release-ci-summary.mjs <full-release-run-id>
その後、有用な場合にのみ監視します:
gh run watch <full-release-run-id> --repo openclaw/openclaw --exit-status
ターンを終了するか戦略を切り替える前に、ウォッチャーを停止してください。
障害トリアージ
- 親SHAと子実行IDを確認します。
- 失敗したジョブのみをリストします:
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' - 失敗した1つのジョブログを取得します。レート制限に達した場合は、リセット時間をメモし、これ以上のREST呼び出しを避けます。
- シークレット関連の障害のように見える場合は、コードを編集する前に、同じシークレットソースからプロバイダーエンドポイントを検証します。
- ライブキャッシュ障害の場合は、キーの欠落/無効、空のテキスト、プロバイダーの拒否、タイムアウト、またはベースラインのミスのいずれかを調査します。明確なプロバイダーエビデンスなしにリリースゲートを弱めないでください。
- 狭く修正し、ローカル/変更された証明を実行し、コミット、プッシュ、最も小さい一致グループを再実行します。
エビデンス
記録:
- リリースSHA
- 完全な親実行URL
- 子実行IDと結果: CI、リリースチェック、プラグインプリリース、NPM Telegram
- 対象のローカル証明コマンド
- プロバイダーシークレット事前確認結果
- 既知のギャップまたは無関係な障害
レッスンと復旧パターンについては、references/release-ci-notes.md を参照してください。