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

Coroid ne marque un déploiement comme effectué que lorsque votre CI/CD l'indique. Cette page explique comment une pipeline signale les déploiements, qu'elle soit lancée par Coroid ou qu'elle s'exécute indépendamment.

Tout ce qui suit est configuré par environnement dans les Paramètres du projet. Paramètres → Versions → Pipeline de déploiement. Créez-y un jeton de signalement. Un Propriétaire ou un Administrateur le voit une seule fois. Stockez-le en tant que secret dans la pipeline d'Intégration Continue de cet environnement. Coroid ne conserve que son hachage ; remplacer le jeton révoque immédiatement l'ancien. Ce jeton ne peut signaler des déploiements que pour son projet et son environnement. Jamais il ne doit être placé dans un fichier de dépôt ou dans une requête navigateur.

GitHub Actions et GitLab CI/CD#

Si vous souhaitez Déployer vers… le bouton sur la page de Release, sélectionnez Coroid lance une workflow GitHub Actions ou Coroid lance une pipeline GitLab CI/CD dans les paramètres de Pipeline de déploiement de l'environnement. Saisissez le nom exact du job de déploiement, la branche ou la référence de tag, ainsi que le nom du fichier de workflow GitHub si applicable. Cette référence doit pointer vers le commit de version au moment de la demande. La workflow GitHub reçoit coroid_release_id, coroid_attempt_id, coroid_commit_sha, et coroid_environment des entrées, plus coroid_version, coroid_build_number et coroid_release_name lorsque la workflow les déclare. GitLab reçoit les variables équivalentes en majuscules COROID_* variables. Utilisez ces valeurs pour déployer et signaler le SHA et l'essai exacts. Incluez la version dans votre build montre comment inscrire la version dans le build.

Stockez le jeton de rappel d'environnement dans les secrets GitHub Actions ou les variables masquées GitLab CI/CD. Envoyez un running événement lorsque le job de déploiement commence et un succeeded, failed, ou cancelled événement une fois son exécution terminée. Coroid vérifie l'exécution du fournisseur, la validation et le job nommé avant d'accepter le succès pour un pipeline configuré. L'URL de l'exécution du fournisseur reste l'endroit où consulter les journaux. Le Workflow de production Coroid contient un exemple concret d'GitHub Actions ; adaptez les noms des secrets et les jobs à votre dépôt.

Callback CI générique#

Un pipeline externe peut envoyer les mêmes événements sans activer la distribution. Authentifiez-vous avec le jeton porteur à portée définie pour 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"
}

Inclure 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 correspond à l'identifiant du projet. failureReason peut expliquer une exécution ayant échoué. Utilisez queued, running, succeeded, failed, ou cancelled pour status. Conservez-en un providerRunId au cours d'une exécution et attribuer à chaque transition d'état un identifiant unique eventId. Une nouvelle tentative de l'événement doit conserver son identifiant ; une nouvelle exécution CI nécessite un nouvel identifiant d'exécution. La date et l'heure de l'événement doivent être récentes. Coroid vérifie le dépôt, l'environnement, la validation, la portée des identifiants et l'état final avant de l'appliquer ; les événements en conflit sont mis en attente pour examen. Une déploiement valide sans version préparée peut générer une version observée, clairement distincte d'une candidature approuvée lors de la phase de pré-vérification.

Pour une pipeline sans rappels automatiques, le Propriétaire ou l'Administrateur peut choisir Enregistrer un déploiement externe sur la page de version. Indiquez l’environnement, le commit correspondant, l’heure et une raison ou une URL de preuve. L’attestation manuelle qui en résulte consigne le résultat sans prétendre que Coroid a exécuté la CI ou franchi une étape de validation.

Articles associés#

• Paramètres de version
• Versions
• Séquences de récupération et de publication
• Inclure la version dans votre build