部署事件与CI集成配置

Coroid 仅在你的 CI/CD 确认后才会标记版本已部署。本页展示了流水线如何上报部署情况，无论是由 Coroid 触发还是自行运行。

以下内容均可在项目的对应环境中进行配置：设置 → 版本发布 → 部署流水线在此处创建一个上报令牌。所有者或管理员仅能查看一次该令牌。将其作为机密信息存储在该环境的 CI 流水线中。Coroid 仅保留其哈希值，替换令牌后会立即吊销旧令牌。该令牌仅能用于上报对应项目和环境的数据。永不将其放入仓库文件或浏览器请求中。

GitHub 操作与 GitLab CI/CD#

如果你希望部署到…在版本发布页面上点击该按钮时，请选择Coroid 会启动一个 GitHub 操作工作流或Coroid 会启动一个 GitLab CI/CD 流水线在对应环境的部署流水线设置中填写上述信息。需输入准确的部署任务名称、分支或标签引用，以及适用的 GitHub 工作流文件名。该引用在请求时需指向对应的发布提交。GitHub 工作流会接收coroid_release_id, coroid_attempt_id, coroid_commit_sha, 和coroid_environment这些输入参数。GitLab 会接收对应的大写COROID_*变量。利用这些值即可完成部署并上报精确的 SHA 值和尝试次数。

将环境回调令牌存储在 GitHub 操作机密信息或 GitLab CI/CD 掩码变量中。发送一个running事件以标识部署任务已开始，再发送终端succeeded, failed, 或cancelled事件以标识部署已完成。Coroid 会在确认对应流水线成功前，先校验提供程序运行记录、提交内容和指定任务名称。提供程序运行页面的 URL 仍是查看日志的位置。Coroid 生产工作流其中包含具体的 GitHub 操作示例；可根据实际仓库情况调整其中的机密信息名称和任务。

通用 CI 回调#

外部流水线无需启用调度功能即可发送相同事件。需使用对应环境的限定 Bearer 令牌进行身份验证。该端点接受具有以下版本格式的 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和attemptId在上报由 Coroid 触发的运行记录时需包含这两项。failureReason可用来解释运行失败的原因。使用queued, running, succeeded, failed, 或cancelled用于status在整个运行过程中保留一个providerRunId并为每次状态转换赋予唯一的eventId同一事件的重试请求应保留原有 ID；新的 CI 运行则需使用新的运行 ID。事件时间戳必须是最新的。Coroid 在应用该事件前会校验仓库、环境、提交内容、凭证范围及终端状态；存在冲突的事件会被暂存以待审核。未准备发布的合法部署也可生成观测到的版本，此类版本与预发布审批通过的候选版本有明显区别。

对于没有回调功能的流水线，所有者或管理员可选择记录外部部署在版本发布页面上点击该选项。需填写环境、匹配的提交、时间以及原因或证据链接。生成的手动认证记录会留存部署结果，但不会宣称 Coroid 执行了 CI 流程或通过相关校验。

相关#

• 版本发布设置
• 版本发布
• 恢复与版本发布链路