Définir la requête de recherche

1. Créez votre requête de recherche en utilisant la même logique que pour une recherche dans l’explorateur de pipeline CI.
2. Choisissez l’un des niveaux suivants pour les événements de pipeline CI :
   • Pipeline : évalue l’exécution d’un pipeline entier, qui est généralement composé d’une ou de plusieurs tâches.
   • Stage : évalue l’exécution d’un groupe composé d’une ou de plusieurs tâches (pour les fournisseurs CI qui prennent en charge les étapes).
   • Job : évalue l’exécution d’un groupe de commandes.
   • Command : évalue les événements de commande personnalisée instrumentés manuellement. Ces événements représentent des commandes individuelles exécutées dans le cadre d’une tâche.
   • All : évalue tous les types d’événements.
3. Choisissez de surveiller un nombre d’événements de pipeline CI, une facette ou une mesure :
   • Nombre d’événements de pipeline CI : utilisez la barre de recherche (facultatif) et ne sélectionnez pas de facette ni de mesure. Datadog évalue le nombre d’événements de pipeline CI sur une période sélectionnée, puis le compare aux conditions de seuil.
   • Dimension : sélectionnez une dimension (une facette qualitative) pour recevoir une alerte en fonction du Unique value count (nombre de valeurs uniques) de la facette.
   • Measure : sélectionnez une mesure (une facette quantitative) pour recevoir une alerte en fonction de la valeur numérique de la facette de pipeline CI (comme avec un monitor de métrique). Sélectionnez simplement le type d’agrégation (min, avg, sum, median, pc75, pc90, pc95, pc98, pc99 ou max).
4. Regroupez les événements de pipeline CI en fonction de plusieurs dimensions (facultatif) :
   • Tous les événements de pipeline CI correspondant à la requête sont agrégés au sein de groupes basés sur la valeur d’un maximum de quatre facettes.
5. Configurez la stratégie de regroupement pour les alertes (facultatif) :
   • Si la requête inclut des critères group by, les alertes multiples appliquent l’alerte à chaque source en fonction des paramètres de votre groupe. Un événement d’alerte est créé pour chaque groupe qui répond aux conditions définies. Par exemple, vous pouvez regrouper une requête par @ci.pipeline.name pour recevoir une alerte distincte pour chaque nom de pipeline CI lorsque le nombre d’erreurs est élevé.

Utiliser des formules et des fonctions

Vous pouvez créer des monitors de pipeline CI à l’aide de formules et de fonctions, par exemple pour surveiller un taux de fréquence d’événement, comme le taux d’échec d’un pipeline (taux d’erreur).

Dans l’exemple ci-dessous, un monitor de taux d’erreur de pipeline est créé à l’aide d’une formule calculant le taux suivant : Nombre d’événements de pipeline ayant échoué (ci.status=error) / Nombre total d’événements de pipeline (aucun filtre). Le monitor est regroupé en fonction de ci.pipeline.name, afin de recevoir une seule alerte par pipeline. Pour en savoir plus, consultez la section Présentation des fonctions.

Définir la requête de recherche

1. Types de monitors courants (facultatif) : offre un modèle de requête pour chacun des types de monitors courants, à savoir New Flaky Test (nouveau test irrégulier), Test Failures (échecs de test) et Test Performance (performances des tests). Ce modèle de requête peut ensuite être personnalisé. Pour en savoir plus sur cette fonctionnalité, consultez la section Suivre les nouveaux tests irréguliers.
2. Créez votre requête de recherche en utilisant la même logique que pour une recherche dans l’explorateur de test CI. Par exemple, vous pouvez rechercher les échecs de test pour la branche main du service de test myapp en utilisant la requête suivante : @test.status:fail @git.branch:main @test.service:myapp.
3. Choisissez de surveiller un nombre d’événements de test CI, une facette ou une mesure :
   • Nombre d’événements de test CI : utilisez la barre de recherche (facultatif) et ne sélectionnez pas de facette ni de mesure. Datadog évalue le nombre d’événements de test CI sur une période sélectionnée, puis le compare aux conditions de seuil.
   • Dimension : sélectionnez une dimension (une facette qualitative) pour recevoir une alerte en fonction du Unique value count (nombre de valeurs uniques) de la facette.
   • Measure : sélectionnez une mesure (une facette quantitative) pour recevoir une alerte en fonction de la valeur numérique de la facette de test CI (comme avec un monitor de métrique). Sélectionnez simplement le type d’agrégation (min, avg, sum, median, pc75, pc90, pc95, pc98, pc99 ou max).
4. Regroupez les événements de test CI en fonction de plusieurs dimensions (facultatif) :
   • Tous les événements de test CI correspondant à la requête sont agrégés au sein de groupes basés sur la valeur d’un maximum de quatre facettes.
5. Configurez la stratégie de regroupement pour les alertes (facultatif) :
   • Si la requête inclut des critères group by, une alerte est envoyée pour chaque source en fonction des paramètres de regroupement. Un événement d’alerte est créé pour chaque groupe qui répond aux conditions définies. Par exemple, vous pouvez regrouper une requête selon @test.full_name pour recevoir une alerte distincte pour chaque nom complet de test CI lorsque le nombre d’erreurs est trop élevé. Le nom complet du test est composé de la collection de tests et du nom du test, par exemple : MySuite.myTest. Dans Swift, le nom complet du test est composé du bundle de test, de la collection de tests et du nom du test, par exemple : MyBundle.MySuite.myTest.

Tests exécutés avec des configurations ou paramètres différents

Utilisez @test.fingerprint dans le paramètre group by du monitor lorsque plusieurs tests ont le même nom complet mais qu’ils utilisent des configurations ou des paramètres de test différents. De cette façon, des alertes se déclencheront pour les exécutions avec des paramètres ou des configurations de test spécifiques. @test.fingerprint offre le même niveau de granularité que la section Test Stats, Failed et Flaky Tests de la page Commit Overview.

Par exemple, si un test avec le même nom complet a échoué sur Chrome mais réussi sur Firefox, l’option fingerprint enverra une alerte pour l’exécution Chrome uniquement.

Ainsi, @test.full_name déclenchera une alerte même si le test a réussi sur Firefox.

Formules et fonctions

Vous pouvez créer des monitors de test CI à l’aide de formules et de fonctions, par exemple pour surveiller un taux de fréquence d’événement, comme le taux d’échec d’un test (taux d’erreur).

Dans l’exemple ci-dessous, un monitor de taux d’erreur de test est créé à l’aide d’une formule calculant le taux suivant : Nombre d’événements de test ayant échoué (@test.status:fail) / Nombre total d’événements de test (aucun filtre). Le monitor est regroupé en fonction de @test.full_name afin de recevoir une seule alerte par test. Pour en savoir plus, consultez la section Présentation des fonctions.

Utiliser CODEOWNERS pour les notifications

Vous pouvez envoyer la notification à différentes équipes en utilisant l’information CODEOWNERS disponible dans l’événement de test.

Dans l’exemple ci-dessous, la notification est configurée avec la logique suivante :

• Si le propriétaire du code est MonOrganisation/mon-équipe, envoyer la notification au canal Slack canal-de-mon-équipe.
• Si le propriétaire du code est MonOrganisation/mon-autre-équipe, envoyer la notification au canal Slack canal-de-mon-autre-équipe.

{{#is_match "citest.attributes.test.codeowners" "MonOrganisation/mon-équipe"}}
  @slack-canal-de-mon-équipe
{{/is_match}}
{{#is_match "citest.attributes.test.codeowners" "MonOrganisation/mon-autre-équipe"}}
  @slack-canal-de-mon-autre-équipe
{{/is_match}}

Dans la section Notification message de votre monitor, ajoutez un bloc semblable à l’exemple ci-dessus pour configurer les notifications du monitor. Vous pouvez ajouter autant de variables is_match que vous le souhaitez. Pour en savoir plus sur les variables de notification, consultez la section Variables conditionnelles des monitors.