デプロイメントイベントとCIのセットアップ

CoRoidがリリースをデプロイと認識するのは、ご自身のCI/CDがそう指定した場合のみです。このページでは、パイプラインがどのようにデプロイ状況を報告するか、CoRoidが開始した場合と自動で実行された場合の両方を説明します。

以下のすべての設定は、プロジェクト内の各環境ごとに行われます。設定 → リリース → デプロイパイプラインそこでレポート用トークンを作成してください。オーナーまたは管理者が一度だけそれを確認できます。その環境のCIパイプライン内でシークレットとして保存してください。CoRoidはハッシュ値のみを保持し、トークンを置き換えると即座に古いトークンは無効になります。このトークンは対象のプロジェクトおよび環境でのみレポートでき、決して実行しないリポジトリファイルやブラウザリクエスト内に記載してはなりません。

GitHubアクションとGitLab CI/CD#

もしあなたがデプロイ先…リリースページ上のボタンを使いたい場合は、次を選択してください。CoRoidがGitHub Actionsワークフローを開始しますまたはCoRoidがGitLab CI/CDパイプラインを開始します環境のデプロイパイプライン設定内で行ってください。正確なデプロイジョブ名、ブランチまたはタグ参照、該当する場合はGitHubワークフロー名を入力してください。要求時にはその参照がリリースコミットを指している必要がありますが、GitHubワークフローがcoroid_artifact_sha入力項目を宣言している場合を除きます。GitHubワークフローはcoroid_release_id、coroid_attempt_id、coroid_commit_sha、およびcoroid_environment入力項目に加えてcoroid_version、coroid_build_number、coroid_release_nameおよびcoroid_artifact_shaワークフローがそれらを宣言している場合。GitLabは同等の大文字形式のCOROID_*変数を受け取ります。これらの値を使って、正確なSHA値と試行回数をデプロイおよびレポートしてください。

GitHub ワークフローで宣言するcoroid_artifact_sha通常はデフォルトブランチの自身の参照から実行され、その入力内のコミットをデプロイします。CoRoidは今日のワークフローを使って任意のリリースをデプロイでき、古いリリースへのロールバックも可能です。その際、参照がリリースコミットを指す必要はなくなります。CoRoidは実行が開始されたコミットを記録し、実行結果を報告する際にそれを確認します。ワークフローではデプロイされたコミットのGitHubデプロイ情報も記録し、そのステータスが実行情報と連携するよう設定する必要があります。これはCoRoidのデプロイチェックが別のコミットから実行が始まった場合にも該当情報を読み取るためです。

デプロイを安全に復旧させるためのさらに2つのオプション入力項目があります。

• coroid_expected_revisionは、デプロイ要求時に環境が実行していたコミットです。デプロイ前に環境が実行しているものと比較してください。もし異なる場合、途中で誰かがデプロイしたことになり、デプロイせずに停止します。
• coroid_rollbackはtrue実行中に環境をロールバックする場合、そのような実行には専用の並列処理グループを割り当てて、デプロイ処理の後ろでロールバックが待機しないようにします。ロールバック前に、CoRoidはまだ実行中のデプロイ処理をキャンセルし、停止するまで待機します。時間内に停止しなかった場合、ロールバックは行われず、オーナーおよび管理者に通知されます。

GitLabはそれらをCOROID_EXPECTED_REVISIONおよびCOROID_ROLLBACK。ビルド内にバージョンを設定するビルドにバージョンを刻印する方法を説明します。

実行ごとに試行回数を名前に含めて付けることで、CoRoidは応答が届いていない実行を特定できます。GitHub Actionsでは、以下を設定してくださいrun-nameにcoroid_attempt_id。GitLab でworkflow:nameに$COROID_ATTEMPT_ID：

# GitHub Actions
run-name: ${{ inputs.coroid_attempt_id && format('Deploy (attempt {0})', inputs.coroid_attempt_id) || 'Deploy' }}

# GitLab CI/CD
workflow:
  name: 'Deploy $COROID_ATTEMPT_ID'

CoRoidが実行を開始したものの、プロバイダーから開始確認が得られない場合、デプロイ処理は待機状態になります。5分経過後、CoRoidは名前に試行回数が含まれる実行を探し、見つかった場合はその実行に従います。15分経過しても実行が見つからない場合、デプロイ処理は失敗とみなされ、リリースは失敗とマークされ、環境は新たなデプロイを受け入れ可能になります。

環境用コールバックトークンは、GitHubアクションのシークレットまたはGitLab CI/CDのマスク済み変数に保存してください。デプロイジョブ開始時にrunningイベントを送信し、終了時にはsucceeded、failed、またはcancelled完了時にイベントが発生します。CoRoidは設定済みのパイプラインに対する成功判定を下す前に、プロバイダーの実行情報、コミット、指定されたジョブを確認します。ログを確認するには引き続きプロバイダーの実行URLを利用してください。

あるコミットから実行され、別のコミットをデプロイするGitHubワークフロー、例えばref入力項目を使って古いコミットをデプロイしたりロールバックしたりする場合、デプロイしたコミットを明記する必要があります。次のようにGitHubデプロイ環境内のデプロイされたコミットに対して作成し、その最終的なsuccessステータスにlog_urlワークフロー実行内容へのリンクを設定します。その後、GitHubアプリはデプロイメント：読み取り専用という権限が必要です。CoRoid本番ワークフロー具体的なGitHubアクションの例が含まれており、シークレット名やジョブを自分のリポジトリに合わせて調整してください。

汎用CIコールバック#

外部パイプラインでも、ディスパッチを有効にせずに同じイベントを送信できます。環境限定のビアラートークンで認証してください。エンドポイントは次のバージョン形式のJSONを受け付けます：

POST /api/v1/release-deployment-events
Authorization: Bearer <environment-callback-token>
Content-Type: application/json

{
  "schemaVersion": 1,
  "eventId": "ci:run-812:production:succeeded",
  "providerRunId": "run-812",
  "projectId": "<project-uuid>",
  "environmentKey": "production",
  "repository": "owner/repository",
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "status": "succeeded",
  "occurredAt": "2026-09-24T12:00:00Z",
  "runUrl": "https://ci.example.com/runs/812"
}

を含めてくださいreleaseIdおよびattemptIdCoRoidが要求した実行をレポートする際に、以下を追加してくださいversionおよびbuildNumberデプロイ内容を記録するために使用します。CoRoid上でホストされるプロジェクトの場合、repositoryはプロジェクトIDです。failureReasonは失敗した実行の理由を説明できます。queued、running、succeeded、failed、cancelled、またはrolled_backのためにstatus・レポートrolled_back実行中に環境がアップグレードされ、新しいバージョンが失敗したため、以前のリビジョンに復元されました。1つのproviderRunId実行中に一貫して使用し、各ステート遷移に固有のeventId。同じイベントの再試行ではIDを保持し、新しいCI実行には新しい実行IDが必要です。GitHubによる再実行ではattemptIdを保持し、その実行試行をレポートします。providerRunId (<run id>-<run attempt>）。環境の最新デプロイを再実行する場合、CoRoidは同じデプロイ処理を継続します。そうでない場合、CoRoidは観測された別のデプロイとして記録します。イベントのタイムスタンプは最近のものである必要があります。CoRoidは適用前にリポジトリ、環境、コミット、認証情報のスコープ、終了状態を確認し、矛盾するイベントはレビュー用に保留されます。準備済みのリリースがない状態でも有効なデプロイが観測されたリリースを生成でき、これは事前承認済みの候補とは明確に区別されます。これにはversionイベントが報告するバージョン、またはCoRoidがプロジェクトのバージョンを割り当てる場合は次のバージョンが使用されます。

イベントのバージョン2 ("schemaVersion": 2)では、デプロイメントの2つの識別情報、すなわち何がデプロイされたかとそれをデプロイしたものが報告されます。artifactにはデプロイされたコミットが格納され、これは必ずcommitShaと一致し、各イメージのダイジェストも含まれます。workflowには実行が開始されたコミットが格納され、オプションでその参照も含まれます。

{
  "schemaVersion": 2,
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "artifact": {
    "sha": "0123456789abcdef0123456789abcdef01234567",
    "images": [{ "name": "app", "digest": "sha256:…" }]
  },
  "workflow": {
    "sha": "89abcdef0123456789abcdef0123456789abcdef",
    "ref": "owner/repository/.github/workflows/deploy.yml@refs/heads/main"
  }
}

ワークフローのコミットがデプロイ要求時のコミットと一致しない場合、またはプロバイダーが別のコミットからの実行を報告する場合、CoRoidはレビュー用にv2イベントを保持します。バージョン1のイベントも引き続き受け付けられます。

コールバック機能のないパイプラインでは、オーナーまたは管理者が選択できます外部デプロイメントを記録リリースページで操作します。環境、一致するコミット、時間、理由または証拠のURLを指定してください。生成される手動の保証情報には結果が記録されますが、CoRoidがCIを実行したりゲートを通過したりしたとは主張されません。

関連項目#

• リリース設定
• リリース
• 復旧とリリーストレイン
• ビルドにバージョンを組み込む