CoroidIhre AI Software-Fabrik
Dokumentation

Ereignisse bei der Bereitstellung und CI-Einrichtung

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

Coroid kennzeichnet einen bereitgestellten Release erst dann, wenn Ihr CI/CD dies bestätigt. Diese Seite zeigt auf, wie eine Pipeline Bereitstellungen meldet – unabhängig davon, ob Coroid diese auslöst oder sie 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 läuft, dann erfolgreich oder fehlgeschlagen
  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 untenstehenden Einstellungen werden pro Umgebung im Projekt unter Einstellungen → Releases → Deploy-Pipeline. Dort ein Reporting-Token erstellen. Ein Inhaber oder Administrator sieht dieses nur einmal. Speichern Sie es als Geheimnis in der CI-Pipeline der jeweiligen Umgebung. Coroid speichert lediglich einen Hashwert; das Ersetzen des Tokens widerruft das alte Token sofort. Das Token kann nur für sein Projekt und seine Umgebung Berichte erstellen. Geben Sie es nie in eine Repository-Datei oder einen Browser-Anfrage ein.

GitHub Aktionen und GitLab CI/CD

Falls Sie den Deployen zu… Button auf der Release-Seite auswählen. Coroid startet einen GitHub Aktionen-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, die Branch- oder Tag-Referenz sowie bei Bedarf den Dateinamen des GitHub-Workflows an. Diese Referenz 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. GitLab erhält die entsprechenden Großbuchstaben- COROID_* Variablen. Nutzen Sie diese Werte zur Bereitstellung und zur Dokumentation des genauen SHA-Werts sowie des Versuchs.

Speichern Sie das Callback-Token der Umgebung in den Geheimnissen von GitHub Aktionen oder den maskierten Variablen von GitLab CI/CD. Senden Sie ein running Ereignis, sobald der Deployment-Job beginnt, sowie ein abschließendes succeeded, failed, oder cancelled Ereignis, wenn dieser abgeschlossen ist. Coroid prüft 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 der Ort zur Einsicht der Protokolle. Der Coroid Produktions-Workflow enthält ein konkretes Beispiel für einen GitHub Aktionen-Workflow; passen Sie dort die Namen der Geheimnisse und Jobs an Ihr Repository an.

Generisches CI-Callback

Eine externe Pipeline kann dieselben Ereignisse senden, ohne Dispatch zu aktivieren. 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. failureReason kann einen fehlgeschlagenen Lauf erklären. Nutzen Sie queued, running, succeeded, failed, oder cancelled für status. Bewahren Sie ein providerRunId über den gesamten Lauf hinweg auf und vergeben Sie für jede Zustandsänderung eine eindeutige eventId. Eine Wiederholung desselben Ereignisses sollte seine ID beibehalten; ein neuer CI-Lauf erfordert eine neue Lauf-ID. Das Zeitstempel des Ereignisses muss aktuell sein. Coroid prüft vor der Anwendung das Repository, die Umgebung, den Commit, den Berechtigungsbereich und den Endzustand; widersprüchliche Ereignisse werden zur Überprüfung zurückgehalten. Eine gültige Bereitstellung ohne vorbereiteten Release kann ein beobachtetes Release erzeugen – dies unterscheidet sich klar von einem vorab genehmigten Kandidaten.

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