Un hook réagit à un événement survenant dans Coroid. Vous choisissez un événement, rédigez les instructions en langage courant, et le hook s'exécute lorsque l'événement est déclenché.
Vous les trouverez dans l'usine logicielle, sous l'onglet Automatisations.
Créez-en un dans Nouveau travail : sélectionnez Automatisation, puis l'option « Lorsqu'une action se produit ». Nouveau travail propose les événements GitHub ainsi que ceux de Coroid. Consultez Automatisations.
Événements auxquels vous pouvez réagir
Un hook ne s'exécute que pour un événement émis par quelque chose. La plupart des événements ci-dessous sont émis par Coroid. Quelques-uns proviennent de vos propres systèmes. Tout autre événement est réservé : l'éditeur ne les liste pas, et la création d'un hook sur l'un d'eux est refusée. Si un hook a été enregistré sur un événement réservé, l'éditeur et la liste l'indiquent comme ne pouvant jamais s'exécuter ; il n'est pas supprimé.
Événements émis par Coroid
| Catégorie | Événements |
|---|---|
| Tâche | Créé, statut modifié, terminé, échoué |
| Agent | Démarré, terminé, erreur |
| Dépôt | Validation de commit, création de branche, ouverture, mise à jour ou fusion de pull request, ouverture d'une issue, commentaire mentionnant Coroid |
| Sprint | Créé, planification démarrée, démarré, tâche ajoutée, tâche supprimée, revue démarrée, terminé, annulé |
| Plan | Phase démarrée, terminée, échouée |
| Planning | Exécution démarrée, exécution terminée, exécution échouée |
| Rapport | Démarré, terminé, échoué |
| Qualité | Vérifier si le processus a démarré, réussi ou échoué ; résolu de manière autonome. |
| Promotion | Demandé, approuvé, rejeté |
| Publication | Créé, modification du candidat, modification des notes, notes approuvées, modification du périmètre, liste de contrôle complétée, évaluation de la validation, validation ignorée, approuvé, publié, annulé. |
| Déploiement | En attente, en cours d'exécution, réussi, échoué, annulé, attesté manuellement, rollback attesté manuellement, vérification de l'état réussie, vérification de l'état échouée |
| Synchroniser | La source externe a été mise à jour |
| Slack et Telegram | Un message correspondant au filtre de l’automatisation |
Événements générés par vos propres systèmes
| Catégorie | Événements |
|---|---|
| Analyse | Dépendance détectée, problème de sécurité identifié, analyse terminée |
| Déploiement externe | En cours, terminé, échoué |
Coroid n'émet pas ces événements. Un pipeline CI, un scanneur ou un autre système de votre organisation déclenche le hook via son identifiant : il appelle POST /api/v1/organizations/hooks/:id/dispatch
avec la clé d'un compte de service
qui possède le hooks:dispatch portée. Le hook s'exécute pour l'événement sur lequel il a été enregistré. L'éditeur liste ces événements sous « Générés par vos propres systèmes ».
Événements réservés
Ces événements n'ont pas encore été envoyés ou déclenchés, donc l'éditeur ne les propose pas :
| Catégorie | Événements |
|---|---|
| Tâche | Changement de phase |
| Agent | Itération, outil utilisé |
| Plan | Créé, phase terminée, révision finale démarrée, révision finale terminée, avant l'pull request du plan |
| Planning | Créé, activé, en pause |
| Sprint | Planification terminée, tâche terminée, périmètre modifié |
| Publication | Prêt à être déployé, validé |
| Promotion | Avant l'pull request de la promotion |
| Qualité | Vérification indisponible ; réparation démarrée ou tentée ; revalidation démarrée ; consensus atteint |
Début et fin des travaux
Les plans, plannings, rapports, contrôles de qualité, promotions et publications envoient un événement lorsqu'ils démarrent et un événement lorsqu'ils se terminent. Un hook peut réagir à la manière dont les travaux se sont terminés, et votre système peut mesurer la durée qu'ils ont pris.
| Travaux | Début | Fin |
|---|---|---|
| Plan | Début de phase : le premier est envoyé lorsque l'exécution du plan commence | Terminé, échoué |
| Planning | Exécution démarrée | Exécution terminée, exécution échouée |
| Rapport | Débuté | Terminé, échoué |
| Contrôle de qualité | Vérification démarrée | Validé, échoué, résolu automatiquement |
| Promotion | Demandé | Approuvé, rejeté |
| Publication | Créé | Publié, annulé |
Chacun de ces événements enregistre l'heure à laquelle il s'est produit dans occurredAt. Un événement qui indique comment les travaux se sont terminés enregistre également l'heure à laquelle ils ont commencé dans
startedAt, et la durée qu'ils ont prise dans durationMs. Cela startedAt est le
occurredAt de l'événement de démarrage ; ainsi, les deux correspondent toujours. Le temps passé en pause compte dans la durée.
Chaque événement est envoyé une seule fois lorsque la modification est enregistrée. Une modification annulée n'envoie rien, et une nouvelle tentative n'envoie rien deux fois. Un événement de fin n'est envoyé que pour les tâches démarrées : une exécution de planification sans résultat n'envoie rien, tout comme un rapport annulé avant son démarrage.
Ce que contient chaque événement, en plus des horaires :
| Événement | Envoyé lorsque | Champs |
|---|---|---|
| Démarrage de la phase de planification | L'exécution du plan commence (sa première phase), et ensuite chaque fois qu'une première tâche d'une autre phase démarre. | planId, plan (id, titre), phase (id, séquence, titre), firstPhase, executionStartedAt |
| Planification terminée ou échouée | L'exécution du plan se termine. Un plan qui échoue pendant sa planification n'envoie rien. | planId, plan, status, executionStartedAt |
| Démarrage d'une exécution de planification | Une exécution de planification démarre. | scheduleId, runId, schedule (id, nom), run (motif de déclenchement, exécution parente) |
| Exécution de planification terminée ou échouée | L'exécution se termine. | Les mêmes champs, status, et tasksCreated ou error |
| Démarrage du rapport | La génération d'un rapport commence. La mise en pause et la reprise conservent le même moment de démarrage. | reportId, report (id, type, titre) |
| Rapport terminé ou échoué | Le rapport est enregistré, ou il échoue ou est annulé. | Les mêmes champs, et tokensUsed, costUsd et hasActionableFindings, ou error |
| Démarrage de la vérification de qualité | Une vérification de qualité démarre. | qualityRunId, check (sujet, déclencheur, version de politique, commit) |
| Vérification de qualité réussie ou échouée | La vérification aboutit à une décision. | Les mêmes champs, decision, redoCause, failedExpectationIds |
| Problème de qualité non résolu automatiquement | Coroid cesse d'essayer de corriger ce qu'a détecté la vérification. | qualityRunId, workItemType, workItemId, reason |
| Demande de promotion | Une promotion est créée | promotionId, laneId, promotion (titre, statut, branches, pull request) |
| La promotion est approuvée | La promotion est fusionnée : approuvée dans Coroid, fusion forcée, fusionnée chez le fournisseur ou livrée dans une version | Les mêmes champs, approval, approvedBy, forceReason |
| La promotion est rejetée | Un réviseur demande des modifications | Les mêmes champs, reason, requestedBy, comment |
| La version est publiée | Le premier déploiement en production de la version réussit | releaseId, version, commitSha |
| La version est annulée | Un retour arrière remplace la version dans un environnement | releaseId, version, rolledBackToReleaseId |
Les événements relatifs au travail dans un projet contiennent également projectId, donc un hook limité à un seul projet ne s'active que pour ce projet. Si un hook a créé le travail, ces événements comptent dans la profondeur de chaîne de ce hook.
Déclencheurs et destinations
Chaque automatisation possède une source de déclenchement, d'où proviennent ses événements, et une destination qui détermine l'action à effectuer lorsqu'un événement est déclenché. Deux des destinations transforment un événement en travail.
| Source de déclenchement | Événements |
|---|---|
| Événement de workflow | Les événements dans Coroid, comme indiqué dans le tableau ci-dessus |
| GitHub | Une demande de fusion est ouverte, mise à jour ou fusionnée ; un ticket est ouvert ; un commentaire mentionnant Coroid |
| Slack | Un message correspondant au filtre de l’automatisation |
| Telegram | Un message correspondant au filtre de l’automatisation, par exemple un message commençant par /coroid |
| Jira | Un nouveau ticket |
| Destination | Ce qui se passe |
|---|---|
| Hook | Exécute vos instructions en mode lecture seule, conformément à ce qui est décrit sur cette page. |
| Valider le travail | Enregistre l'événement en tant que demande. Une fois la validation réussie, Coroid crée le travail. |
| Coroid Check | Obsolète. La révision Coroid de chaque pull request est définie dans Contrôle qualité; les automatisations existantes ont été mises en pause. |
Les événements GitHub nécessitent l'application GitHub. Un commentaire mentionnant Coroid ne compte que si son auteur dispose d'un accès en écriture au dépôt. Voir GitHub.
Une tâche issue de la validation du travail ne démarre pas automatiquement sauf si l'auteur de l'événement est de confiance : l'auteur d'un GitHub, d'un pull request, d'un ticket ou d'un commentaire disposant d'un accès en écriture au dépôt. Les auteurs provenant de Slack, Telegram ou Jira ne sont jamais considérés comme de confiance, donc leurs tâches attendent qu'une personne les lance. Voir Lorsque le travail démarre.
Les nouveaux tickets Jira n'arrivent sur Coroid que via son webhook Jira. Il n'accepte que les livraisons signées avec le secret du webhook configuré pour Coroid, uniquement pour les nouveaux tickets et seulement lorsque la clé du projet Jira correspond à un projet Coroid. Sur coroid.ai, le webhook Jira n'est pas encore configuré, donc aucun événement n'est reçu par le déclencheur Jira ; il faut alors importer les tickets Jira. Lorsque le webhook est configuré, un nouveau ticket est envoyé aux automatisations du déclencheur Jira, comme la source de demande Jira dans le Contrôle qualité, qui crée des tickets des types et priorités choisis pour la qualification. Sans automatisation sur le déclencheur, aucun ticket n'est créé. Le travail à partir de Jira ne démarre jamais seul. Voir Suivi de tickets.
En lecture seule par défaut
Les hooks analysent et génèrent des rapports. Ils peuvent créer des tâches suivantes ; ils ne modifient pas directement votre code.
Cette configuration par défaut les rend faciles à adopter. Une automatisation qui modifie le code en réponse à un événement agit au moment où la supervision est le moins probable. Un hook qui ouvre une tâche produit le même résultat par la voie normale — spécification, planification, vérification, revue, pull request.
- PlanificationHeure
- Automatisation d'événementsUn événement se produit.
Une tâche ordinaire
Spécification, plan, développement, vérification, revue. Utilise un emplacement d'agent ; attribuez-lui une priorité plus faible.
P2P3Un pull request
Il ne peut pas fusionner lui-même ni valider dans votre branche de base.
Vous approuvez
Rédiger de bonnes instructions
Les instructions de hook sont traitées par un modèle, elles ressemblent donc à des instructions destinées à un collègue plutôt qu'à du code. Le niveau de qualité est identique à celui d'une spécification: indiquer ce à quoi regarder, ce qui compte, et ce à faire.
Soyez précis concernant le cas « ne rien faire ». Sans cela, un hook trouvera toujours quelque chose à dire à chaque exécution, et les hooks qui se déclenchent sans cesse sont ignorés par les utilisateurs.
Garde-fous
Trois protections existent car l'automatisation pilotée par événements échoue de manière prévisible :
Limites de fréquence. Par minute, par heure et par jour, configurables par hook. Un hook lié à un événement à haute fréquence peut sinon se déclencher des centaines de fois lors d'une fusion chargée.
Profondeur de chaîne. Les hooks peuvent déclencher des événements qui déclenchent d'autres hooks. Une profondeur maximale de chaîne empêche cela de devenir une boucle.
Permissions des outils. Ce qu'un hook peut accéder est contrôlé — l'accès en lecture seule, les appels MCP et la création de tâches sont gérés séparément.
Permissions
Seuls les propriétaires et administrateurs peuvent créer, modifier, tester ou supprimer un hook ; tous les membres peuvent consulter les hooks et leur historique d'exécution. Étant donné qu'un hook fonctionne avec une portée au niveau de l'organisation, cette asymétrie est volontaire.
Les surveiller
La page de chaque hook dans l'usine liste ses exécutions et ses actions sur les 30 derniers jours : exécutions, échecs et coût. Chaque exécution d'automatisation figure également dans Paramètres → Activité, filtrée par Automatisation. Vérifiez ses exécutions après avoir activé un nouveau hook — le mode d'échec n'est pas une erreur, mais un déclenchement constant sans résultat exploitable.
Hooks et plannings
| Mécanisme | Déclenché par |
|---|---|
| Hook | Un événement de plateforme |
| Planning | Heure |
Tous deux sont des automatisations, listées ensemble dans l'usine. Voir Automatisations.