Débloquer une PR

Résumé d'une ligne : Enquêter sur un pipeline CI défaillant d'une PR — attribuer chaque défaillance à un test instable, une infrastructure ou une régression et proposer une action ciblée.

Requis : skill dd-pup (CLI pup installée et authentifiée), skill triage-flaky-test (pour enquête approfondie sur défaillances instables).

Backend

Détection — Au début de chaque invocation, avant toute action, déterminez quel backend utiliser :

1. Si l'utilisateur a passé --backend pup n'importe où → utilisez pup mode immédiatement. Ignorez les étapes 2–4.
2. Vérifiez si search_datadog_ci_pipeline_events figure dans vos outils disponibles.
3. Si présent → utilisez MCP mode partout. Appelez les outils exactement comme nommés dans les sections workflow de ce skill.
4. Si absent → vérifiez si pup est exécutable : lancez pup --version via Bash. Une réponse JSON contenant "version" confirme que pup est disponible.
5. Si pup répond → utilisez pup mode partout. Traduisez chaque appel d'outil en utilisant l'appendice Référence des outils au bas de ce fichier.
6. Si aucun n'est disponible → arrêtez et dites à l'utilisateur :

   "Neither the Datadog MCP server nor the pup CLI is available. Connect the MCP server or install pup (brew install datadog-labs/pack/pup)."

Règles d'invocation pup :

• Invoquez via Bash. pup génère toujours du JSON — analysez directement.
• Les IDs de repository passés à pup doivent être entièrement en minuscules (l'API rejette les casses mixtes) : github.com/datadog/my-repo, pas github.com/DataDog/my-repo.
• Si pup retourne 401/403, dites à l'utilisateur de lancer pup auth refresh ou pup auth login.

Entrée

Workflow

ÉTAPE 0 — Analyser l'entrée

Dérivez l'ID du repository et la branche par défaut de git si non fournis :

# ID du repository : URL entièrement en minuscules, sans schéma (l'API rejette les casses mixtes)
git remote get-url origin
# Supprimez le protocole et le .git final, puis mettez en minuscules le résultat
# ex. https://github.com/DataDog/my-repo.git → github.com/datadog/my-repo

# Branche par défaut
git symbolic-ref refs/remotes/origin/HEAD
# Supprimez le préfixe refs/remotes/origin/ — revenez à main si non défini

ÉTAPE 1 — Récupérer le résumé CI de la PR (exécutez en parallèle)

Défaillances du pipeline :

Tool: search_datadog_ci_pipeline_events
query: @ci.status:error @git.branch:<branch> @git.repository.id_v2:"<repo>"
ci_level: job
from: now-24h

Défaillances de test (uniquement si les résultats du pipeline incluent des jobs de test-runner) :

Tool: search_datadog_test_events
query: @test.status:fail @git.branch:<branch> @git.repository.id_v2:"<repo>"
from: now-24h
test_level: test

Exécutez les deux en parallèle. Collectez toutes les valeurs @test.service distinctes des résultats d'événements de test. Si plus d'un service distinct est trouvé, notez chacun séparément dans le résumé de triage — ne les fusionnez pas dans un filtre de service unique. Si les résultats du pipeline contiennent seulement des types de jobs d'infrastructure (build, lint, deploy) sans sortie de test-runner, ignorez les résultats de test et passez à l'ÉTAPE 3.

ÉTAPE 1.5 — Récupérer la santé de la PR (exécutez en parallèle avec l'ÉTAPE 1)

Cette étape s'exécute sans conditions — le contexte de santé de la PR est utile que le CI soit rouge ou vert.

Couverture de code (les deux modes) :

Tool: get_datadog_code_coverage_branch_summary
repository_id: <repo>
branch: <branch>

Résolution du numéro de PR (MCP mode uniquement — ignorez si le numéro de PR est déjà fourni en entrée) :

Tool: get_prs_by_head_branch
repo_url: https://<repo>
head_branch: <branch>

Utilisez la première PR ouverte retournée. Si aucune PR ouverte n'est trouvée, ignorez les récupérations de qualité/sécurité et rapportez "No data available" pour Quality et Security.

Qualité du code et sécurité (MCP mode uniquement — uniquement si le numéro de PR est disponible) :

Tool: search_pr_insights
repo_url: https://<repo>
pr_number: <pr_number>

Extrayez uniquement code_quality et code_security de products_status. Ignorez failed_tests, flaky_tests et failed_jobs — les données CI proviennent des ÉTAPES 1–3.

Note du mode pup : la résolution du numéro de PR et search_pr_insights ne sont pas disponibles en pup. Quality et Security affichent toujours "No data available" en mode pup.

ÉTAPE 2 — Blame Guard par Job défaillant

D'abord vérifiez si @error_classification.domain / @error_classification.type sont présents sur les événements de job de l'ÉTAPE 1 — s'ils sont remplis, utilisez-les comme signaux de classification primaires.

Pour chaque job défaillant où la classification est encore nécessaire, lancez les deux vérifications en parallèle :

Vérification de la branche par défaut — ce job échouait-il déjà avant cette PR ?

Tool: aggregate_datadog_ci_pipeline_events
query: @ci.status:error @ci.job.name:"<job>" @git.branch:<default-branch> @git.repository.id_v2:"<repo>"
ci_level: job
aggregation: count
from: now-24h

Vérification du rayon de blast — ce job échoue-t-il sur d'autres branches aussi ?

Tool: aggregate_datadog_ci_pipeline_events
query: @ci.status:error @ci.job.name:"<job>" @git.repository.id_v2:"<repo>"
ci_level: job
aggregation: count
group_by: ["@git.branch"]
from: now-24h

Secours de performance : si la requête du rayon de blast est lente ou expire, ignorez-la et fiez-vous à la vérification de la branche par défaut seule.

ÉTAPE 3 — Classer chaque défaillance

Ordre de priorité :

1. Si @error_classification.domain / @error_classification.type présents → utilisez comme signal primaire
2. Si défaillance de test ET test dans get_datadog_flaky_tests avec flaky_test_state:active → flaky
3. Utilisez les résultats du blame guard :

ÉTAPE 4 — Produire le résumé de triage

Une entrée par job défaillant :

PR CI Triage Brief
==================
Branch:   <branch>
Repo:     <repo>

Job: <job-name>
  Classification:  <flaky | infra | regression | unknown>
  Evidence:        <1 point de données clé — message d'erreur, nombre de pipelines, ou résultat de test>
  Confidence:      <high | medium | low>
  Recommended:     <action>

[répétez pour chaque job défaillant]

Overall: <N> failures — <ex. "1 regression, 1 flaky, 1 infra">

PR Health
=========
Coverage:   <X>% on <branch> | No data available
Quality:    <N violations (X high, Y medium)> | No violations | No data available
Security:   <N violations> | No violations | No data available

Les trois lignes apparaissent toujours. Utilisez "No data available" quand un outil n'a retourné aucune donnée ou n'est pas disponible (mode pup pour Quality/Security).

ÉTAPE 5 — Proposer des actions

regression → Invitez l'utilisateur à enquêter sur ses changements de code. Aucune action d'écriture disponible.

flaky → Chargez le skill triage-flaky-test pour enquête approfondie. Ce skill va :

• Tenter un correctif natif à l'agent en utilisant flaky_category + stack trace
• Proposer une mise en quarantaine via update_datadog_flaky_test_states si un correctif rapide n'est pas possible

infra → Avant de proposer une nouvelle tentative, évaluez si la défaillance est transitoire :

• Vérifiez @error_classification.type et le message d'erreur pour des signaux comme timeout, runner unavailable, network error, quota exceeded — défaillances transitoires où une nouvelle tentative est susceptible d'aider
• Si l'erreur est déterministe (erreur de configuration build, secret manquant, assertion de test explicite), une nouvelle tentative n'aidera probablement pas — suggérez enquêter sur la cause racine
• Si la défaillance préexiste sur la branche par défaut, informez l'utilisateur — une nouvelle tentative échouera probablement à nouveau ; attendez plutôt le correctif en amont

Si transitoire :

Mode MCP — GitHub Actions : utilisez retry_datadog_ci_job. À partir de l'événement du job défaillant, collectez :

• @ci.provider.name → ci_provider ("github")
• @git.repository.id_v2 → repository_id
• @ci.job.id → job_id
• champ id de l'événement → event_uuid (optionnel)

Pour pipeline_id : utilisez @ci.pipeline.id s'il contient un tiret (ex. 26027867390-1). S'il est nu, combinez avec @github.run_attempt : "{@ci.pipeline.id}-{@github.run_attempt}". Secours : analysez @ci.pipeline.url pour runs/{run_id}/attempts/{attempt}.

Après que la nouvelle tentative revienne, confirmez via search_datadog_ci_pipeline_events (query: @ci.job.name:"<job>" @git.branch:<branch>, from: now-5m) qu'une nouvelle exécution apparaît.

Secours / mode pup — GitHub Actions : extrayez l'ID d'exécution de @ci.pipeline.url :

gh run rerun <run_id> --failed

GitLab / autres fournisseurs (les deux modes) : partagez @ci.pipeline.url et dirigez vers l'interface utilisateur du fournisseur.

unknown → Suggérez de vérifier les logs de job bruts via l'interface utilisateur du fournisseur CI ou @ci.pipeline.url à partir de l'événement du pipeline.

Référence des outils

Cet appendice s'applique uniquement en pup mode. En mode MCP, utilisez directement les noms d'outils dans les sections workflow.