Driftsättningshändelser och CI-konfiguration

CoRoid markerar bara en release som driftsatt när din CI/CD säger det. På den här sidan visas hur en pipeline rapporterar driftsättningar, oavsett om CoRoid startar den eller om den körs på egen hand.

Allt nedan konfigureras per miljö under projektets Inställningar → Versioner → Distribuera-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 sparar bara en hash, och om du byter ut tokenen återkallas den gamla omedelbart. Tokenen kan bara rapportera för sitt projekt och sin miljö. Lägg den aldrig i en repo-fil eller en webbläsarförfrågan.

GitHub Actions och GitLab CI/CD#

Om du vill ha knappen Distribuera 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 Distribuera-pipeline. Ange det exakta namnet på distributionsjobbet, branch- eller tagg-referensen och filnamnet för GitHub-arbetsflödet när det är aktuellt. Referensen måste peka på versions-committen när begäran görs, såvida inte GitHub- arbetsflödet deklarerar en coroid_artifact_sha indata (se nedan). GitHub- arbetsflödet får coroid_release_id, coroid_attempt_id, coroid_commit_sha, och coroid_environment indata, samt coroid_version, coroid_build_number, coroid_release_name och coroid_artifact_sha när arbetsflödet deklarerar dem. GitLab får motsvarande versalerade COROID_* variabler. Använd dessa värden för att distribuera och rapportera exakt SHA och försök.

Ett GitHub-arbetsflöde som deklarerar coroid_artifact_sha körs från sin egen ref, vanligtvis din standardbranch, och driftsätter den commit som anges i indata. CoRoid kan därefter driftsätta vilken release som helst, även återställa till en äldre, med dagens arbetsflöde. Ref behöver då inte längre peka på releasens commit. CoRoid registrerar vilken commit körningen startade från och kontrollerar den när körningen rapporteras. Arbetsflödet bör också registrera en GitHub-driftsättning av den driftsatta committen, med en status som länkar till körningen, eftersom CoRoids driftsättningskontroll läser den när körningen startade från en annan commit.

Ytterligare två valfria indata gör distributioner säkra att återställa:

• coroid_expected_revision är committen som miljön körde när distributionen begärdes. Jämför den med det som miljön kör innan du distribuerar. Om de skiljer sig åt har någon distribuerat under tiden, så avbryt utan att distribuera.
• coroid_rollback är true när körningen återställer miljön. Ge sådana körningar en egen samtidighetsgrupp, så att en återställning aldrig behöver vänta bakom en driftsättning. Innan en återställning avbryter CoRoid en driftsättning som fortfarande körs och väntar tills den har stoppats. Om den inte stoppas i tid återställs ingenting, och Ägare och Administratörer får ett meddelande.

GitLab tar emot dem som COROID_EXPECTED_REVISION och COROID_ROLLBACK. Lägg in versionsnumret i din build visar hur du bäddar in versionsnumret i builden.

Namnge varje körning efter dess försök, så att CoRoid kan hitta en körning som den aldrig fick någon bekräftelse på att hade startat. I GitHub Actions anger du run-name till en text som innehåller coroid_attempt_id. I GitLab anger du workflow:name till en text som innehåller $COROID_ATTEMPT_ID:

# GitHub Actions
run-name: ${{ inputs.coroid_attempt_id && format('Deploy (attempt {0})', inputs.coroid_attempt_id) || 'Deploy' }}

# GitLab CI/CD
workflow:
  name: 'Deploy $COROID_ATTEMPT_ID'

Om CoRoid startar en körning men leverantören aldrig bekräftar att den startat, väntar driftsättningen. Efter 5 minuter söker CoRoid efter en körning med försöket i namnet och följer den om den hittas. Om ingen körning hittas efter 15 minuter avslutas driftsättningen som förlorad, releasen markeras som misslyckad och miljön tar emot en ny driftsättning.

Spara miljöns callback-token i GitHub Actions-hemligheter eller GitLab CI/CD maskerade variabler. Skicka en running -händelse när distributionsjobbet startar och en terminal succeeded, failed, eller cancelled -händelse när den är klar. CoRoid kontrollerar leverantörens körning, commit och namngivna jobb innan den godkänner att en konfigurerad pipeline har lyckats. Leverantörens URL till körningen är fortfarande platsen där du granskar loggarna.

Ett GitHub-arbetsflöde som körs från en commit och distribuerar en annan, till exempel ett med indatan ref för att distribuera en äldre commit eller återställa, måste ange vilken commit det distribuerade. Skapa en GitHub-distribution för den distribuerade committen i miljön och ge dess slutliga success status en log_url som länkar till arbetsflödeskörningen. GitHub-appen behöver då behörigheten Distributioner: endast läsåtkomst. CoRoid produktionsarbetsflöde 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 den här versionshanterade strukturen:

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. Lägg till version och buildNumber för att registrera vad du driftsatte. För ett projekt som finns på CoRoid, repository projekt-ID:t. failureReason kan förklara en misslyckad körning. Använd queued, running, succeeded, failed, cancelled, eller rolled_back för status. Rapportera rolled_back när körningen uppgraderade miljön och sedan återställde den tidigare revisionen eftersom den nya misslyckades. 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. En GitHub-omkörning behåller attemptId och rapporterar sitt körningsförsök i providerRunId (<run id>-<run attempt>). Om den kör om miljöns senaste driftsättning följer CoRoid samma driftsättning. Annars registrerar CoRoid den som en separat driftsättning som den har observerat. Händelsens tidsstämpel måste vara aktuell. CoRoid kontrollerar repo, miljö, commit, behörighetsomfång och terminaltillstånd innan den tillämpar händelsen. Motstridiga händelser hålls för granskning. En giltig driftsättning utan en förberedd release kan skapa en observerad release, tydligt åtskild från en kandidat som godkänts i förkontrollen. Den får version det som händelsen rapporterar eller, när CoRoid tilldelar projektets versioner, nästa version.

Version 2 av händelsen ("schemaVersion": 2) rapporterar också de två identiteterna för en distribution separat: vad som distribuerades och vad som distribuerade det. artifact innehåller den distribuerade committen, som måste vara samma som commitSha, och digesten för varje avbild. workflow innehåller committen som körningen startade från och eventuellt dess ref:

{
  "schemaVersion": 2,
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "artifact": {
    "sha": "0123456789abcdef0123456789abcdef01234567",
    "images": [{ "name": "app", "digest": "sha256:…" }]
  },
  "workflow": {
    "sha": "89abcdef0123456789abcdef0123456789abcdef",
    "ref": "owner/repository/.github/workflows/deploy.yml@refs/heads/main"
  }
}

CoRoid håller en v2-händelse för granskning när arbetsflödets commit inte är den som driftsättningen begärdes vid, eller när leverantören visar att körningen startade från en annan commit. Händelser i version 1 godkänns fortfarande.

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

Relaterat#

• Versionsinställningar
• Versioner
• Återställning och versionsflöden
• Lägg in versionsnumret i din build