Examen de PR par la communauté

Étant donné un numéro de PR ou un nom de branche, déterminez si elle est prête pour un examen humain.

Étapes

1. Résoudre la PR

Si un nom de branche est donné, trouvez d'abord le numéro de PR :

gh pr view <branch> --repo n8n-io/n8n --json number --jq .number

2. Récupérer les données de la PR

gh pr view <number> --repo n8n-io/n8n \
  --json number,title,body,author,headRefName,headRefOid,files,isDraft,state

Récupérez en parallèle :

# Statut de commit CLA (signal principal) — les statuts sont les plus récents en premier ; utilisez la première entrée retournée
gh api --paginate "repos/n8n-io/n8n/commits/<headRefOid>/statuses" \
  --jq '[.[] | select(.context == "license/cla") | {state, description}] | first'

# Commentaire de problème CLAassistant (solution de secours quand pas de statut de commit) — utilisez la dernière entrée retournée
gh api --paginate "repos/n8n-io/n8n/issues/<number>/comments" \
  --jq '[.[] | select(.user.login == "CLAassistant") | .body] | last'

# Commentaires d'examen de PR cubic-dev-ai (diffusés pour que les résultats se concatènent correctement entre les pages)
gh api --paginate "repos/n8n-io/n8n/pulls/<number>/comments" \
  --jq '.[] | select(.user.login == "cubic-dev-ai[bot]") | {body: .body, path: .path}'

3. Exécuter les cinq vérifications

A. CLA signé

Vérifiez d'abord le statut de commit license/cla ; retournez au commentaire CLAassistant si aucun statut n'existe.

Statut de commit (context == "license/cla"):

state: "success" → ✅ signé
state: "failure" ou state: "error" → ❌ non signé
state: "pending" → ⏳ en attente
Absent → retournez au commentaire

Commentaire de problème CLAassistant (solution de secours):

Le corps contient "All committers have signed the CLA." → ✅ signé
Le corps contient "not signed" ou un lien pour signer → ❌ non signé
Aucun commentaire → ❌ traiter comme non signé

B. Format du titre de la PR

Pour tous les types sauf revert, le titre doit correspondre à :

^(feat|fix|perf|test|docs|refactor|build|ci|chore)(\([a-zA-Z0-9 ]+( Node)?\))?!?: [A-Z].+[^.]$

Pour les titres revert, le résumé est l'en-tête de commit original (qui commence par un type minuscule), donc la majuscule n'est pas imposée :

^revert(\([a-zA-Z0-9 ]+( Node)?\))?!?: .+[^.]$

Le type doit être l'un de : feat fix perf test docs refactor build ci chore revert
La portée est optionnelle, entre parenthèses ex : (editor) ou (Slack Node)
Changements cassants : ! avant les deux-points
Résumé : commence par une majuscule (minuscule acceptée pour revert:), pas de point à la fin
Pas d'identifiants de ticket Linear dans le titre (ex : N8N-1234)

C. Complétude de la description de la PR

Résumé (## Summary) — doit avoir du contenu non vide sous le titre (pas juste le commentaire HTML).
Tickets connexes (## Related Linear tickets, Github issues, and Community forum posts) — contenu acceptable : une URL (http), un mot-clé de fermeture GitHub (closes #N, fixes #N, resolves #N, etc.), ou vide. Ne marquer que si l'en-tête de section est complètement absent.
Liste de contrôle (## Review / Merge checklist) — tous les quatre éléments doivent être présents. Les cases non cochées sont attendues pour les PR communautaires ; ne les marquer pas comme manquantes.

D. Tests

Ignorez cette vérification si le type de PR (du titre) est docs, ci, chore, ou build.

Sinon :

Identifiez les fichiers source modifiés : fichiers non-test sous packages/ de la liste files.
S'il y a des modifications de fichiers source, vérifiez la PR dans un worktree temporaire :

git fetch origin pull/<number>/head:pr/<number>
git worktree add /tmp/pr-<number>-review pr/<number>

Lisez les fichiers source modifiés du worktree pour déterminer si les modifications introduisent une logique qui justifie des tests (nouvelles fonctions, corrections de bogues, changements de comportement, transformations de données). Les changements purs de config, les changements de type uniquement et les renommages triviaux ne nécessitent pas de tests.
Recherchez les fichiers de test correspondants (*.test.ts, *.spec.ts, fichiers dans __tests__/) parmi les fichiers modifiés.
Nettoyez toujours le worktree, même si une vérification précédente a échoué :

git worktree remove /tmp/pr-<number>-review --force
git branch -D pr/<number>

Rapportez :

✅ Tests présents, ou changement ne nécessitant pas de tests
❌ Logique source modifiée mais aucun fichier de test trouvé

E. Problèmes cubic-dev-ai

Examinez les commentaires d'examen de PR récupérés à l'étape 2. cubic-dev-ai[bot] laisse des commentaires pour chaque problème qu'il trouve.

Aucun commentaire de cubic-dev-ai[bot], ou chaque commentaire indique explicitement qu'aucun problème n'a été trouvé → ✅
N'importe quel autre commentaire → ❌ rapportez le compte total et la ventilation des priorités (ex : « 3 problèmes : 1× P1, 1× P2, 1× P3 »)

4. Sortie

Toujours sortir un JSON valide dans cette forme exacte :

{
  "readyForReview": <true si tous les contrôles réussis permettent la fusion, false sinon>,
  "messageForUser": "<Résumé lisible par un humain de ce qui doit changer, écrit comme s'il était posté directement au contributeur de la PR. 'N/A' si rien n'est nécessaire.>",
  "checks": {
    "CLA": <true si signé, false si non signé ou en attente>,
    "Title": <true si le titre respecte la convention, false sinon>,
    "Description": <true si les trois sections du modèle sont complètes, false sinon>,
    "TestsNeeded": <true si les modifications du code nécessitent des tests, false si non applicable>,
    "TestsIncluded": <true si les fichiers de test sont présents dans la PR, false sinon>,
    "CubicIssues": <true si cubic-dev-ai a soulevé des problèmes, false si aucun problème>
  }
}

readyForReview est true uniquement quand : CLA, Title et Description sont tous true ; CubicIssues est false ; et soit TestsNeeded est false soit TestsIncluded est true.

messageForUser doit être un court message sympathique adressé au contributeur énumérant exactement ce qu'il doit traiter. Si readyForReview est true, mettez-le à "N/A".

Sortir uniquement le bloc JSON.

Notes

PRs en brouillon — rapportez tous les résultats mais notez que la PR est un brouillon.
Si la PR est déjà fusionnée ou fermée, dites-le et ignorez les vérifications.
Toujours supprimer le worktree même si des vérifications antérieures ont échoué.

community-pr-review