Coroid prend de nombreuses décisions lors du traitement d'une tâche : déterminer si une demande doit effectivement donner lieu à du travail, comment la réaliser, et si le résultat est suffisamment satisfaisant pour vous être présenté. Certaines décisions ne quittent jamais les mains des personnes. La fusion est l'exemple le plus clair.
Décisions prises par Coroid
- Déterminer si une demande donne lieu à du travail. Éligibilité Vérifications de doublons, d'éléments déjà corrigés ou impossibles à reproduire. Pour les demandes arrivant sans intervention humaine, l'admission décide ensuite selon vos mandats si le travail peut commencer maintenant, plus tard ou pas du tout.
- Comment le travail est construit et vérifié. Le plan, le code, les tests, les seuils de qualité, les contrôles de qualité et la phase de révision. Voir Comment Coroid vérifie son propre travail.
- Ce qu'il aurait fait concernant la fusion. Coroid enregistre un jugement sur chaque pull request qu'il examine, sans en tirer de conséquence. Voir Comment Coroid vérifie son propre jugement.
Décisions qui restent entre les mains des personnes
| Décision | Qui la prend |
|---|---|
| Fusionner un pull request dans votre branche | Une personne, au sein de GitHub ou GitLab, ou avec Approuver & fusionner dans Coroid |
| Publier et déployer | Une personne, via votre pipeline ou une publication dans Coroid |
| Préciser l'objet du travail automatisé et son budget | Un propriétaire ou administrateur, en publiant un mandat |
| Définir ce que signifie « terminé » pour une tâche | La personne qui l'a demandée, dans son contrat de résultat |
| Créer du travail – Éligibilité bloquée | Une personne ayant les droits nécessaires, avec Créer du travail quand même et une raison |
Coroid ne fusionne jamais seul, et aucun paramètre ne permet de le faire. Voir Fusion.
Les mandats ne changent pas qui effectue la fusion
Un mandat permet de lancer le travail sans qu’on ait à demander chaque étape individuellement. Il n’autorise pas pour autant que le résultat soit validé sans l’accord d’une personne. Le travail initié via un mandat suit la même procédure de vérification que toute autre tâche et aboutit au même résultat : une demande de fusion qui attend l’approbation humaine.
Ce qu’un mandat apporte, c’est la traçabilité du travail non supervisé : les projets qu’il peut concerner, le montant qu’il peut dépenser, ainsi qu’un historique de chacune de ses décisions.
Comment Coroid vérifie son propre jugement
Pour chaque pull request soumis à l’examen par Coroid, et pour chaque tâche prête à être fusionnée, Coroid note la décision qu’il aurait prise s’il avait été autorisé à effectuer la fusion :
- Approuverait. Toutes les conditions requises sont remplies et conformes : les contrôles de qualité sur le dernier commit de l’pull request, l’avis de Coroid, les vérifications du fournisseur, une fusion sans conflit, et pour une tâche, les résultats des tests et l’avis du réviseur.
- Refuserait. Au moins un de ces critères bloque la validation.
- Impossible de se prononcer. Une information nécessaire manquait. L’absence de preuve ne constitue jamais une approbation.
Ce jugement n’est jamais affiché dans l’pull request, ne modifie aucune tâche et ne déclenche aucune fusion. Il n’apparaît pas encore dans Coroid.
Coroid compare ensuite chaque jugement avec ce qui s’est produit après la fusion :
- un message ultérieur de pull request intitulé Annuler… marque l’entrée précédente comme annulée;
- un message ultérieur de pull request indiquant Corrige #n marque pull request n comme correctif urgent appliqué;
- sur l’écran de révision de la tâche, sous Ce qui s’est passé après la fusion, toute personne au sein de l’organisation peut marquer une pull request fusionnée comme annulée, corrigée à chaud ou anomalie signalée.
Une approbation accordée à un pull request qui a ensuite été annulé ou corrigé compte comme une mauvaise approbation. Au sein de son propre dépôt, Coroid introduit également délibérément des copies altérées de modifications réelles afin de mesurer ses capacités de détection.
Pourquoi conserver cet historique ?
Afin que la question « Peut-on faire confiance à Coroid pour fusionner ce type de modification ? » puisse être répondue grâce à des données concrètes — la fréquence à laquelle ses approbations se révèlent erronées, pour quel type de modifications, sur combien d’exemples — plutôt qu’à la simple intuition. Pour l’instant, rien n’agit en fonction de cet historique. Si cela devait changer un jour, ce serait une décision explicite prise par un responsable, et cet historique servirait de base à cette décision.