CoroidYour AI software factory
Documentation

Deployment events and CI setup

Connect GitHub Actions, GitLab CI/CD, or another CI system to view the deployment history in Releases.

Coroid only marks a release as deployed when your CI/CD confirms it. This page explains how a pipeline reports deployments, whether Coroid initiates them or they run autonomously.

Coroid

Your CI/CD

Environment

  1. 1.Start for the exact commit
  2. 2.Deploy the pinned commit
  3. 3.Report running, then succeeded or failed
  4. 4.Watch health with the canary check
A deployment counts only after your pipeline reports success. Step 1 is skipped when your pipeline starts on its own.

All settings below are configured per environment in the project's Settings → Releases → Deploy pipeline. Create a reporting token there. An Owner or Admin views it once. Store it as a secret in the CI pipeline for that environment. Coroid retains only a hash, and replacing the token instantly revokes the old one. The token can only report for its specific project and environment. Never include it in a repository file or a browser request.

GitHub Actions and GitLab CI/CD

If you require the Deploy to… button on the release page, select Coroid initiates a GitHub Actions workflow or Coroid starts a GitLab CI/CD pipeline in the Deploy pipeline settings for that environment. Enter the precise deployment job name, the branch or tag reference, and the GitHub workflow filename where applicable. That reference must point to the release commit at the time of the request. The GitHub workflow receives coroid_release_id, coroid_attempt_id, coroid_commit_sha, and coroid_environment inputs. GitLab receives the equivalent uppercase COROID_* variables. Use these values to deploy and record the exact SHA and attempt number.

Store the environment callback token in GitHub Actions secrets or GitLab CI/CD masked variables. Send a running event when the deployment job starts and a terminal succeeded, failed, or cancelled event when it finishes. Coroid verifies the provider run, commit, and named job before confirming success for a configured pipeline. The provider run URL remains the place to inspect logs. The Coroid production workflow contains a practical GitHub Actions example; adjust its secret names and jobs to match your repository.

Generic CI callback

An external pipeline can send the same events without enabling dispatch. Authenticate using the environment's scoped bearer token. The endpoint accepts JSON requests with this versioned format:

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"
}

Include releaseId and attemptId when reporting a run requested by Coroid. failureReason can detail a failed run. Use queued, running, succeeded, failed, or cancelled for status. Keep one providerRunId throughout a run and assign a unique eventId. A retry of the same event should retain its ID; a new CI run requires a new run ID. The event timestamp must be recent. Coroid checks the repository, environment, commit, credential scope, and terminal state before applying it; conflicting events are held for review. A valid deployment without a prepared release can generate an observed release, which differs clearly from a preflight-approved candidate.

For a pipeline without callbacks, an Owner or Admin can select Record external deployment on the release page. Specify the environment, matching commit, time, and a reason or evidence URL. The resulting Manual attestation records the outcome without implying that Coroid ran CI or passed a gate.