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

Coroidがリリースがデプロイされたと判断するのは、ご自身のCI/CDがそう報告した場合のみです。このページでは、パイプラインがどのようにデプロイメントを報告するか、Coroidがそれを開始したか、あるいは独自に実行されたかを説明します。

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

GitHub ActionsおよびGitLab CI/CD#

もしご希望であればデプロイ先…リリースページ上のボタンから、次を選択してくださいCoroidがGitHub Actionsワークフローを開始しますまたはCoroidがGitLab CI/CDパイプラインを開始しますこれらは環境の「デプロイパイプライン」設定内で指定します。正確なデプロイジョブ名、ブランチまたはタグ参照、該当する場合はGitHubワークフローファイル名を入力してください。この参照先はリクエスト時点でリリースコミットを指している必要があります。GitHubワークフローは以下の情報を受け取りますcoroid_release_id、coroid_attempt_id、coroid_commit_sha、およびcoroid_environment入力値に加えてcoroid_version、coroid_build_numberおよびcoroid_release_nameワークフロー内で宣言されている場合はこれらも含まれます。GitLabはそれに相当する大文字のCOROID_*変数を受け取ります。これらの値を利用して、正確なSHA値および試行回数をデプロイおよび報告できます。ビルド内にバージョンを組み込むビルドにバージョンを刻印する方法を解説します。

環境用のコールバックトークンは、GitHub ActionsのシークレットまたはGitLab CI/CDのマスク済み変数に保存してください。runningデプロイジョブが開始された際にeventを送信し、終了時にsucceeded、failed、またはcancelledイベントが完了した際に、Coroidはプロバイダーの実行内容、コミット情報、および指定されたジョブを確認し、設定済みのパイプラインで正常に処理されたかを判定します。ログを確認するには引き続きプロバイダーの実行URLを利用してください。Coroidの本番ワークフロー具体的なGitHub Actionsの例が記載されており、シークレット名やジョブ名をご自身のリポジトリに合わせて調整してください。

汎用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のためにstatus。1つのproviderRunId実行中に一貫して使用し、各ステータス遷移には一意のeventId。同一イベントの再試行時にはIDを維持し、新しいCI実行の場合は新しい実行IDを付与します。イベントのタイムスタンプは最新である必要があります。Coroidはリポジトリ、環境、コミット、認証範囲、最終ステータスを確認した上で処理を適用し、矛盾するイベントはレビュー待ちとなります。準備済みのリリースがない状態での有効なデプロイでも観測可能なリリースが生成され、これはプリフライト承認済みの候補とは明確に区別されます。

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

関連項目#

• リリース設定
• リリース
• 復旧処理とリリース工程
• ビルドにバージョン情報を含める