GitHub の交付と失敗復旧
開発の交付、昇格、候補ビルド、正式リリースを区別します。
Clowld Space 自身の開発で使う拡張フローです。GitHub の権限と、対応するブランチ・チェック・リリースワークフローが必要です。任意のリポジトリを接続するだけではリリースパイプラインは導入されません。GitHub 連携から設定してください。
4つの段階
| 段階 | 操作 | 完了条件 |
|---|---|---|
| 開発の交付 | 機能ブランチから dev へ PR を作成し Auto-merge を申請 | 申請は待機状態。実際のマージでブランチに反映 |
| 昇格 | 検証済み dev のスナップショットを promote/* PR で main へ | 昇格 PR のマージ |
| 候補ビルド | 確定コミットの成果物を準備・検証 | ワークフロー成功と、タスクに紐づく候補証跡の確認 |
| 正式リリース | 許可済みのバージョン Tag を作成しリリースを実行 | 正式ワークフローの成功。候補成功だけでは未リリース |
Auto-merge 申請後、開発エージェントは交付を終了でき、GitHub がチェックとマージを処理します。タスクの自動完了には終了キーワードや他の未完了 PR の条件も必要です。GitHub 連携を参照してください。
失敗通知
結果、PR またはワークフローへのリンク、コミット、失敗ジョブがタスクのコメントに記録されます。開発復旧は開いている PR の現在のコミットで Dev PR Gate が失敗した場合に限ります。ドラフト、古いコミット、キャンセルのみの開発チェックでは新規復旧を開始しません。
昇格には Promotion Gate を使います。Actions の読み取り権限と workflow_job 購読があればジョブ失敗時に早期通知でき、なければ全体の結果で報告します。候補と正式リリースの結果は対応タスクへの紐づけが必要です。
復旧と人による判断
対象の失敗は調整役 Coco に渡されます。利用可能なエージェント、ランタイム、実行権限が必要で、失敗コメントだけでは修復が実行された証明になりません。同じ Webhook は復旧回数に重複計上せず、同じコミットの新しい失敗試行は計上できます。
同じ失敗が2回連続、または復旧失敗が計3回になると自動復旧を止め、人の判断を求めます。昇格・候補・正式リリースでは元の担当者を維持します。タイムラインとログで原因を確認し、阻害要因を解消して既存の許可範囲で続けてください。待機や再試行は成功ではありません。
昇格成功はリリース許可を付与しません。許可がない場合はリリース意思の確認段階で止まります。
本ページは現在のコードを説明します。旧バックエンドでは GitHub 連携の自動完了設定とバージョンガイドを確認してください。