CoroidIhre AI Software-Fabrik
Dokumentation

Einsatzereignisse und CI-Einrichtung

Verbinden Sie GitHub Actions, GitLab CI/CD oder ein anderes CI-System mit dem Deployment-Verlauf von Releases.

Coroid kennzeichnet einen Release erst dann als deployed, wenn Ihr CI/CD dies bestätigt. Diese Seite zeigt auf, wie eine Pipeline Deployment-Ereignisse meldet – unabhängig davon, ob Coroid den Prozess startet oder die Pipeline eigenständig läuft.

Coroid

Ihr CI/CD

Umgebung

  1. 1.Starten für den exakten Commit
  2. 2.Bereitstellen der fixierte Commit
  3. 3.Bericht Es wird ausgeführt, anschließend erfolgreich oder fehlgeschlagen – samt der eingesetzten Version.
  4. 4.Systemzustand überwachen mit der Canary-Prüfung
Ein Deployment gilt erst als abgeschlossen, wenn Ihr Pipeline den Erfolg meldet. Schritt 1 entfällt, wenn Ihr Pipeline automatisch startet.

Alle nachfolgenden Einstellungen werden pro Umgebung im Projekt in den Einstellungen → Releases → Deploy-Pipeline. Dort erstellen Sie ein Reporting-Token. Ein Inhaber oder Administrator sieht dieses nur einmal. Speichern Sie das Token als Geheimnis in der CI-Pipeline der jeweiligen Umgebung. Coroid speichert lediglich den Hashwert; ein Austausch des Tokens widerruft das alte sofort. Das Token darf nur für sein zugehöriges Projekt und seine Umgebung Berichte erstellen. Geben Sie es niemals in einer Repository-Datei oder einer Browser-Anfrage an.

GitHub Actions und GitLab CI/CD

Falls Sie den Deploy zu… Button auf der Release-Seite auswählen möchten, wählen Sie Coroid startet einen GitHub Actions-Workflow oder Coroid startet eine GitLab CI/CD-Pipeline in den Einstellungen der Deploy-Pipeline der Umgebung. Geben Sie dort den exakten Namen des Deployment-Jobs, den Branch- oder Tag-Ref sowie bei Bedarf den Dateinamen des GitHub-Workflows an. Dieser Ref muss zum Zeitpunkt der Anfrage auf den Release-Commit verweisen. Der GitHub-Workflow erhält coroid_release_id, coroid_attempt_id, coroid_commit_sha, und coroid_environment Eingaben, zusätzlich coroid_version, coroid_build_number und coroid_release_name falls der Workflow diese deklariert. GitLab erhält die entsprechenden Großbuchstaben- COROID_* variablen. Nutzen Sie diese Werte, um den genauen SHA-Wert und Versuchszahl beim Deployment und zur Berichterstattung festzuhalten. Die Version im Build festlegen zeigt auf, wie die Version im Build eingetragen wird.

Speichern Sie das Callback-Token der Umgebung in Geheimnissen von GitHub Actions oder in maskierten Variablen von GitLab CI/CD. Senden Sie ein running Ereignis, sobald der Deployment-Job startet, sowie ein abschließendes succeeded, failed, oder cancelled Ereignis, wenn der Job beendet ist. Coroid prüft zuvor den Provider-Lauf, den Commit und den benannten Job, bevor es einen erfolgreichen Abschluss für eine konfigurierte Pipeline bestätigt. Die URL des Provider-Laufs bleibt die Stelle, um die Protokolle einzusehen. Das Coroid-Produktionsworkflow enthält ein konkretes Beispiel für einen GitHub Actions-Workflow; passen Sie dort die Namen der Geheimnisse und Jobs an Ihr Repository an.

Allgemeines CI-Callback

Eine externe Pipeline kann dieselben Ereignisse ohne Aktivierung von Dispatch senden. Authentifizieren Sie sich mit dem bereichsspezifischen Bearer-Token der Umgebung. Der Endpunkt akzeptiert JSON in folgender versionierter Form:

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

Fügen Sie releaseId und attemptId hinzu, wenn Sie einen von Coroid angeforderten Lauf melden. Fügen Sie version und buildNumber hinzu, um festzuhalten, was deployed wurde. Bei einem Projekt, das auf Coroid gehostet wird, ist repository die Projekt-ID. failureReason kann einen fehlgeschlagenen Lauf erklären. Nutzen Sie queued, running, succeeded, failed, oder cancelled für status. Verwenden Sie ein einziges providerRunId über den gesamten Lauf hinweg und geben Sie jedem Zustandswechsel eine eindeutige eventId. Eine Wiederholung desselben Ereignisses sollte seine ID beibehalten; ein neuer CI-Lauf erfordert eine neue Run-ID. Das Zeitstempel-Datum des Ereignisses muss aktuell sein. Coroid prüft vor der Anwendung das Repository, die Umgebung, den Commit, den Berechtigungsscope und den Endzustand; widersprüchliche Ereignisse werden zur Überprüfung zurückgehalten. Ein gültiges Deployment ohne vorbereiteten Release kann ein beobachtetes Release erzeugen – dies ist klar vom vorab genehmigten Kandidaten zu unterscheiden.

Bei einer Pipeline ohne Callbacks können ein Inhaber oder Administrator den Externes Deployment aufzeichnen auf der Release-Seite auswählen. Geben Sie dabei die Umgebung, den passenden Commit, die Uhrzeit sowie einen Grund oder eine URL zu den Nachweisen an. Die daraus resultierende manuelle Bestätigung dokumentiert das Ergebnis – ohne zu behaupten, dass Coroid CI durchgeführt oder eine Prüfung bestanden hat.