Événements de déploiement et configuration de l'CI

CoRoid ne marque une version comme déployée que si votre CI/CD l'indique. Cette page explique comment un pipeline signale les déploiements, qu'il soit lancé par CoRoid ou qu'il s'exécute de manière autonome.

Tout ce qui suit est configuré par environnement dans les Paramètres du projet. Paramètres → Versions → Pipeline de déploiement. Créez un jeton de signalement à cet endroit. Un Propriétaire ou un Administrateur le voit une seule fois. Stockez-le en tant que secret dans le pipeline CI de cet environnement. CoRoid ne conserve que son hachage ; remplacer le jeton révoque immédiatement l'ancien. Le jeton ne peut signaler des données que pour son projet et son environnement. Ne l'insérez jamais dans un fichier du dépôt ni dans une requête navigateur.

Actions GitHub et GitLab CI/CD#

Si vous souhaitez Déployer vers… sur la page de version, sélectionnez CoRoid lance un workflow Actions de GitHub ou CoRoid lance un pipeline CI/CD de GitLab dans les paramètres du pipeline de déploiement de l'environnement. Saisissez le nom exact de la tâche de déploiement, la branche ou la référence de balise, ainsi que le nom du fichier de workflow GitHub si applicable. Cette référence doit pointer vers la validation de version au moment de la demande, sauf si le workflow GitHub déclare une coroid_artifact_sha le workflow GitHub reçoit coroid_release_id, coroid_attempt_id, coroid_commit_sha, et coroid_environment entrées, plus coroid_version, coroid_build_number, coroid_release_name et coroid_artifact_sha lorsque le workflow les déclare. GitLab reçoit les variables équivalentes en majuscules COROID_* . Utilisez ces valeurs pour déployer et signaler le SHA et la tentative exacts.

Un workflow GitHub qui déclare coroid_artifact_sha s'exécute à partir de sa propre référence, généralement votre branche par défaut, et déploie la validation présente dans cette entrée. CoRoid peut ensuite déployer n'importe quelle version, y compris une restauration vers une version antérieure, avec le workflow actuel ; la référence n'a plus besoin de pointer vers la validation de la version. CoRoid enregistre la validation à partir de laquelle le run a été lancé et la vérifie lorsque le run signale des informations. Le workflow doit également enregistrer un déploiement GitHub de la validation déployée, dont le statut lie le run, car la vérification de déploiement de CoRoid le lit lorsque le run est lancé à partir d'une autre validation.

Deux autres entrées optionnelles rendent les déploiements faciles à récupérer :

• coroid_expected_revision est la validation que l'environnement exécutait au moment de la demande de déploiement. Comparez-la avec celle en cours d'exécution avant de déployer. Si elles diffèrent, quelqu'un a effectué un déploiement entre-temps ; arrêtez donc sans déployer.
• coroid_rollback est true lorsqu'un run effectue une restauration de l'environnement. Attribuez à ces runs leur propre groupe de concurrence afin qu'une restauration n'attende jamais derrière un déploiement. Avant une restauration, CoRoid annule tout déploiement encore en cours et attend qu'il se termine. Si celui-ci ne s'arrête pas à temps, aucune restauration n'est effectuée et les Propriétaires ainsi que les Administrateurs en sont informés.

GitLab les reçoit sous forme de COROID_EXPECTED_REVISION et COROID_ROLLBACK. Incluez la version dans votre build. montre comment inscrire la version dans le build.

Nommez chaque run d'après sa tentative afin que CoRoid puisse trouver un run dont il n'a jamais reçu de retour sur le démarrage. Dans Actions de GitHub, configurez run-name sur du texte contenant coroid_attempt_id. Dans GitLab, définissez workflow:name sur du texte contenant $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'

Si CoRoid lance un run mais que le fournisseur ne confirme jamais son démarrage, le déploiement reste en attente. Après 5 minutes, CoRoid recherche un run dont le nom contient la tentative ; s'il en trouve un, il suit ce run. Si aucun run n'est trouvé après 15 minutes, le déploiement est considéré comme perdu, sa version est marquée comme ayant échoué et l'environnement accepte un nouveau déploiement.

Stockez le jeton de rappel d'environnement dans les secrets d'Actions GitHub ou les variables masquées GitLab CI/CD. Envoyez un événement running lorsque la tâche de déploiement commence et un événement terminal succeeded, failed, ou cancelled Événement déclenché à la fin de l'exécution. CoRoid vérifie l'exécution du fournisseur, le commit et le job nommé avant d'accepter la réussite pour un pipeline configuré. L'URL de l'exécution du fournisseur reste l'endroit où consulter les journaux.

Un workflow GitHub qui s'exécute à partir d'une validation et déploie une autre, par exemple avec une ref entrée pour déployer une validation ancienne ou effectuer une restauration, doit indiquer quelle validation a été déployée. Créez une Déploiement GitHub pour la validation déployée dans l'environnement, et attribuez-lui le success statut final un log_url qui lie l'exécution du workflow. L'application GitHub a alors besoin de la permission de dépôt Déploiements : Lecture seule. Le Workflow de production CoRoid contient un exemple concret d'Actions GitHub ; adaptez les noms de secrets et les tâches à votre dépôt.

Rappel CI générique#

Un pipeline externe peut envoyer les mêmes événements sans activer le dispatch. Authentifiez-vous avec le jeton porteur à portée de l'environnement. Le point de terminaison accepte JSON avec cette structure versionnée :

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

Incluez releaseId et attemptId lors de la notification d'une exécution demandée par CoRoid. Ajoutez version et buildNumber pour enregistrer ce qui a été déployé. Pour un projet hébergé sur CoRoid, repository est l'ID du projet. failureReason peut expliquer une exécution ayant échoué. Utilisez queued, running, succeeded, failed, cancelled, ou rolled_back pour status. Rapport rolled_back lorsque l'exécution a mis à jour l'environnement, puis restauré la version précédente car la nouvelle version était défaillante. Conservez une providerRunId au cours d'une exécution et attribuez à chaque transition d'état un identifiant unique eventId. Une nouvelle tentative du même événement doit conserver son identifiant ; une nouvelle exécution CI nécessite un nouvel identifiant d'exécution. Une ré-exécution de GitHub conserve le attemptId et signale sa tentative d'exécution dans le providerRunId (<run id>-<run attempt>) Si l'environnement est réexécuté avec le dernier déploiement, CoRoid suit ce même déploiement. Sinon, CoRoid le enregistre comme un déploiement distinct qu'il a observé. L'horodatage de l'événement doit être récent. CoRoid vérifie le dépôt, l'environnement, la validation, la portée des identifiants et l'état terminal avant d'appliquer le déploiement ; les événements conflictuels sont mis en attente pour examen. Un déploiement valide sans version préparée peut générer une version observée, clairement distincte d'une candidature approuvée en phase de pré-validation. Il prend en charge version L'événement indique la version à utiliser ou, lorsque CoRoid attribue les versions du projet, la suivante.

La version 2 de l'événement ("schemaVersion": 2) signale également les deux identités d'un déploiement : ce qui a été déployé et ce qui l'a déployé. artifact contient le commit déployé, qui doit être égal à commitSha, ainsi que le résumé de chaque image. workflow Contient la validation à partir de laquelle le processus a démarré, et éventuellement sa référence :

{
  "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 génère un événement de type v2 en attente de validation lorsque la validation du workflow n'est pas celle pour laquelle le déploiement a été demandé, ou lorsque le fournisseur indique que l'exécution démarre à partir d'une autre validation. Les événements de version 1 restent acceptés.

Pour un pipeline sans rappels automatiques, un Propriétaire ou un Administrateur peut choisir Enregistrer le déploiement externe sur la page de la release. Indiquez l’environnement, le commit correspondant, l’heure et un motif ou une URL vers des éléments de preuve. L’attestation manuelle consigne le résultat sans prétendre que CoRoid a exécuté la CI ni passé un contrôle.

Liés#

• Paramètres de la version
• Versions
• Chaînes de récupération et de publication
• Incorporez la version dans votre build