CoroidDin AI-plattform för mjukvaruutveckling
Dokumentation

Driftsättningshändelser och CI-konfiguration

Anslut GitHub Actions, GitLab CI/CD eller ett annat CI-system till versionshistoriken för driftsättningar.

Coroid markerar en version som driftsatt först när din CI/CD anger det. Här visas hur en pipeline rapporterar driftsättningar, oavsett om Coroid startar den eller om den körs på egen hand.

Coroid

Din CI/CD

Miljö

  1. 1.Starta för exakt den commiten
  2. 2.Driftsätt den fastlåsta commiten
  3. 3.Rapportera Körs och blir sedan godkänt eller misslyckas, med den version som distribuerades.
  4. 4.Övervaka systemhälsan med canary-kontrollen
En driftsättning räknas först när din pipeline rapporterar att körningen lyckades. Steg 1 hoppas över om pipelinen startar av sig själv.

Allt nedan konfigureras per miljö under projektets Inställningar → Versioner → Deploy pipeline. Skapa en rapporteringstoken där. En Ägare eller Administratör ser den bara en gång. Spara den som en hemlighet i CI-pipelinen för den miljön. Coroid lagrar bara en hash, och om du ersätter tokenen återkallas den gamla omedelbart. Tokenen kan bara rapportera för sitt projekt och sin miljö. Lägg aldrig in den i en repository-fil eller en webbläsarförfrågan.

GitHub Actions och GitLab CI/CD

Om du vill ha knappen Driftsätt till… på versionssidan väljer du Coroid startar ett GitHub Actions-arbetsflöde eller Coroid startar en GitLab CI/CD-pipeline i miljöns inställningar för Deploy pipeline. Ange det exakta namnet på driftsättningsjobbet, branch- eller tag-refen och filnamnet för GitHub-arbetsflödet när det är relevant. Refen måste peka på versions-committen när förfrågan görs. GitHub- arbetsflödet får coroid_release_id, coroid_attempt_id, coroid_commit_sha, och coroid_environment som indata, samt coroid_version, coroid_build_number och coroid_release_name när arbetsflödet deklarerar dem. GitLab får motsvarande versaler i COROID_* variablerna. Använd dessa värden för att driftsätta och rapportera exakt SHA och körningsförsök. Lägg in versionen i bygget visar hur du stämplar versionen i bygget.

Spara miljöns callback-token i GitHub Actions-secrets eller som maskerade variabler i GitLab CI/CD. Skicka en running -händelse när driftsättningsjobbet startar och en slutlig succeeded, failed, eller cancelled -händelse när det avslutas. Coroid kontrollerar leverantörens körning, commit och namngivna jobb innan en konfigurerad pipeline godkänns som lyckad. URL:en till leverantörens körning är fortfarande platsen där du granskar loggarna. Coroid-produktionsarbetsflödet innehåller ett konkret exempel med GitHub Actions. Anpassa namnen på hemligheterna och jobbet till din repository.

Generisk CI-callback

En extern pipeline kan skicka samma händelser utan att aktivera dispatch. Autentisera med miljöns avgränsade bearer-token. Slutpunkten tar emot JSON med följande versionshanterade 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"
}

Ta med releaseId och attemptId när du rapporterar en körning som begärts av Coroid. Lägg till version och buildNumber för att registrera vad du driftsatte. För ett projekt som finns på Coroid är repository projekt-ID:t. failureReason kan förklara varför en körning misslyckades. Använd queued, running, succeeded, failed, eller cancelled för status. Behåll ett och samma providerRunId genom hela körningen och ge varje statusövergång ett unikt eventId. Ett nytt försök med samma händelse ska behålla sitt ID; en ny CI-körning behöver ett nytt körnings-ID. Händelsens tidsstämpel måste vara aktuell. Coroid kontrollerar repository, miljö, commit, behörighetens omfattning och slutstatus innan den tillämpas. Motstridiga händelser hålls för granskning. En giltig driftsättning utan en förberedd version kan skapa en observerad version, tydligt åtskild från en kandidat som godkänts i förkontrollerna.

För en pipeline utan callbacks kan en Ägare eller Administratör välja Registrera extern driftsättning på versionssidan. Ange miljön, matchande commit, tid och en orsak eller URL till underlag. Den resulterande manuella attesteringen registrerar utfallet utan att påstå att Coroid körde CI eller klarade en kontroll.