Coroid markerar bara en release som distribuerad när ditt CI/CD anger det. Den här sidan visar hur en pipeline rapporterar distributioner, oavsett om Coroid startar den eller om den körs på egen hand.
Coroid
Din CI/CD
Miljö
- 1.Start för den exakta commiten
- 2.Driftsätt den låsta commiten
- 3.Rapport körs och lyckas eller misslyckas sedan
- 4.Övervaka hälsostatus med canary-kontrollen
Allt nedan konfigureras per miljö i projektets Inställningar → Releaser → Deploy pipeline. Skapa en rapporteringstoken där. En Ägare eller Administratör ser den en gång. Lagra den som en hemlighet i CI-pipelinen för den miljön. Coroid behåller bara en hash, och om du ersätter token återkallas den gamla omedelbart. Token kan bara rapportera för sitt projekt och sin miljö. Placera den Aldrig i en repository-fil eller i en webbläsarförfrågan.
GitHub Actions och GitLab CI/CD
Om du vill ha knappen Deploy to… på releasesidan väljer du Coroid
startar ett arbetsflöde i GitHub Actions eller Coroid startar en GitLab CI/CD-pipeline
i miljöns inställningar för Deploy pipeline. Ange det exakta namnet på deployment-jobbet,
branch- eller tag-referensen och filnamnet för GitHub-arbetsflödet när det är
aktuellt. Referensen måste peka på release-committen vid tidpunkten för begäran. GitHub-
arbetsflödet tar emot coroid_release_id, coroid_attempt_id,
coroid_commit_sha, och coroid_environment -indata. GitLab tar emot motsvarande versaler i COROID_* -variablerna. Använd dessa värden för att distribuera och rapportera exakt SHA och försök.
Lagra miljöns callback-token i GitHub Actions-hemligheter eller i GitLab CI/CD-
maskerade variabler. Skicka en running -händelse när deployment-jobbet startar och en terminal succeeded, failed, eller cancelled -händelse när det är klart. Coroid
kontrollerar providerns körning, commit och namngivna jobb innan en lyckad körning godkänns för en
konfigurerad pipeline. URL:en till providerns körning är fortfarande platsen där du granskar loggarna. Coroid produktionsarbetsflöde
innehåller ett konkret exempel med GitHub Actions. Anpassa dess hemlighetsnamn och jobb till
din repository.
Generisk CI-callback
En extern pipeline kan skicka samma händelser utan att aktivera dispatch. Autentisera med miljöns begränsade bearer-token. Slutpunkten accepterar 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"
}Inkludera releaseId och attemptId när du rapporterar en körning som begärts av
Coroid. failureReason kan förklara en misslyckad körning. 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, autentiseringsuppgifternas omfattning och terminalstatus innan den tillämpas; motstridiga händelser hålls för granskning. En giltig distribution utan en förberedd release kan skapa en observerad release, tydligt åtskild från en kandidat som godkänts i förkontrollen.
För en pipeline utan callback kan en Ägare eller Administratör välja Registrera extern distribution på releasesidan. Ange miljön, matchande commit, tid och en orsak eller evidens-URL. Den resulterande manuella attesteringen registrerar utfallet utan att hävda att Coroid körde CI eller klarade en kontroll.