CoroidYour AI software factory
Documentation

Deployment events and CI setup

Connect GitHub Actions, GitLab CI/CD, or another CI system to Release deployment history.

Coroid only marks a release deployed when your CI/CD says so. This page shows how a pipeline reports deployments, whether Coroid starts it or it runs on its own.

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.

Everything below is configured per environment in the project's Settings → Releases → Deploy pipeline. Create a reporting token there. An Owner or Admin sees it once. Store it as a secret in that environment's CI pipeline. Coroid keeps only a hash, and replacing the token revokes the old one immediately. The token can report only for its project and environment. Never put it in a repository file or a browser request.

GitHub Actions and GitLab CI/CD

If you want the Deploy to… button on the release page, choose Coroid starts a GitHub Actions workflow or Coroid starts a GitLab CI/CD pipeline in the environment's Deploy pipeline settings. Enter the exact deployment job name, the branch or tag ref, and the GitHub workflow filename when applicable. That ref must point to the release commit at request time. 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 report the exact SHA and attempt.

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 checks the provider run, commit, and named job before accepting success for a configured pipeline. The provider run URL remains the place to inspect logs. The Coroid production workflow contains a concrete GitHub Actions example; adapt its secret names and job to your repository.

Generic CI callback

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

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 explain a failed run. Use queued, running, succeeded, failed, or cancelled for status. Keep one providerRunId throughout a run and give each state transition a unique eventId. A retry of the same event should retain its ID; a new CI run needs a new run ID. The event timestamp must be recent. Coroid checks 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 create an observed release, clearly separate from a preflight-approved candidate.

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