Documentation

Vérifications, exécutions et résultats

Lire une exécution de vérification, trier les constatations et décider des actions à entreprendre.

Une vérification est une vérification unique. Une exécution correspond à une exécution des vérifications dans une politique appliquée à un changement. Une constatation est ce qu'une vérification a rapporté.

Les constatations d'une tâche se trouvent dans sa section Contrôle qualité , et chaque exécution est suivie dans l'Usine. Paramètres → Activité.

Lire une exécution

Une exécution affiche chaque vérification, son résultat et sa sortie. Lorsqu'une tâche échoue à la vérification, c'est dans l'exécution que vous découvrirez la raison.

Lisez-le du haut vers le bas. La première vérification en échec est généralement la cause réelle ; les échecs ultérieurs sont souvent des conséquences. Un échec de compilation suivi de douze échecs de test constituent un seul problème, pas treize.

Constatations

Les constatations proviennent des agents de révision, des analyseurs et des portes d'admission consultatives. Chacune indique ce qui a été trouvé, où et son niveau de gravité. Une constatation liée à une tâche reste associée à cette dernière. Un échec de test qui n'est rattaché à aucune tâche est placé dans l'Usine en phase de Révision, où vous pouvez le corriger ou l'accepter en indiquant la raison. Un contrôle qui ne peut pas s'exécuter dans un projet, comme des tests unitaires sans cadre de test, est signalé dans la section Contrôle qualité.

Leur cycle de vie :

  1. Signalée par une vérification ou un réviseur.
  2. Routée — les constatations pouvant être corrigées sont renvoyées à l'agent développeur pour retravail ; les autres sont associées à pull request.
  3. Résolue — corrigée, acceptée ou supprimée.

Signalés

  • Une porte d'alerte
  • L'agent réviseur
  • Un analyseur connecté

Dirigés

Correctibles

Retour au développeur sous forme de retravail

Le reste

Joint au pull request

Résolus

  • Corrigés

    Le changement y remédie

  • Acceptés

    C'est vrai, mais pas nécessaire d'agir ici. Indiquez la raison.

  • Supprimés

    Faux positif ou règle non applicable. Indiquez la raison.

Les anomalies pouvant être corrigées sont traitées pendant l'exécution. Les autres parviennent au pull request, et chaque anomalie est résolue, acceptée ou supprimée, avec une justification pour ces deux derniers cas.

Trier

La question pour chaque constatation n'est pas « est-ce vrai ? » mais « cela change-t-il ce qui se passe ensuite ? ».

  • Corriger maintenant — correction de bugs, sécurité, tout ce qui échouerait à la révision de toute façon.
  • Accepter — constatation vraie mais ne méritant pas d'action ici. Notez la raison.
  • Supprimer — faux positif, ou règle ne s'appliquant pas à ce code.

Supprimez délibérément et en indiquant une raison. Une suppression non expliquée est indiscernable de quelqu'un qui étouffe une vérité gênante ; six mois plus tard, personne ne pourra distinguer l'une de l'autre.

Lorsqu'il y a trop de constatations

Le volume est un signal sur la configuration, pas sur la qualité du code.

Une vérification déclenchée sur la plupart des changements ne détecte pas de problèmes ; elle décrit simplement votre base de code. Soit la règle ne correspond pas à vos conventions, soit elle décrit une dette technique que vous avez choisi d'accepter. Dans les deux cas, la vérification est mal configurée.

Constatations et portes

Une constatation issue d'une porte d'avis est une information. La même constatation issue d'une porte bloquante arrête la tâche. La constatation est identique ; la politique détermine son impact.

C'est la solution à utiliser lorsqu'une vérification est correcte mais trop agressive : modifiez sa gravité plutôt que de la supprimer. Consultez Politiques de qualité et portes.