Créer une Pull Request

Crée des PR GitHub avec des titres qui passent la validation CI check-pr-title de n8n.

Format du titre de PR

<type>(<scope>): <summary>

Types (obligatoire)

Scopes (optionnel mais recommandé)

• API - Modifications de l'API publique
• benchmark - Modifications de la CLI benchmark
• core - Core/backend/API privée
• editor - Modifications de l'interface éditeur
• * Node - Nœud spécifique (ex. : Slack Node, GitHub Node)

Règles de résumé

• Utiliser l'impératif présent : « Add » au lieu de « Added »
• Capitaliser la première lettre
• Pas de point à la fin
• Pas d'ID de ticket (ex. : N8N-1234)
• Ajouter le suffixe (no-changelog) pour exclure du changelog

Étapes

1. Vérifier l'état actuel :

   git status
   git diff --stat
   git log origin/master..HEAD --oneline

2. Vérifier un plan d'implémentation : Chercher un fichier de plan dans .claude/plans/ qui correspond à l'ID du ticket de la branche actuelle (ex. si la branche est scdekov/PAY-1234-some-feature, chercher .claude/plans/PAY-1234.md). Si un fichier de plan existe, demander à l'utilisateur s'il souhaite l'inclure dans la description de PR sous forme de section <details> repliable (voir section Plan ci-dessous). Inclure le plan uniquement si l'utilisateur approuve explicitement.

3. S'il s'agit d'un correctif de sécurité, auditer tous les artefacts publics avant de continuer (voir Correctifs de sécurité ci-dessous).

4. Analyser les modifications pour déterminer :

   • Type : Quel type de modification est-ce ?
   • Scope : Quel package/domaine est affecté ?
   • Summary : Que fait la modification ?

5. Pousser la branche si nécessaire :

   git push -u origin HEAD

6. Créer la PR en utilisant gh CLI. Lire .github/pull_request_template.md comme structure du corps, puis remplir chaque section avec le contenu réel avant de créer la PR :

   • Summary : décrire ce que la PR fait et comment la tester
   • Related tickets : ajouter l'URL du ticket Linear (https://linear.app/n8n/issue/[TICKET-ID]) et tout lien vers un issue GitHub
   • Checklist : garder tel quel du template
   • Ajouter un « 🤖 PR Summary generated by AI » à la fin du corps

   gh pr create --draft --title "<type>(<scope>): <summary>" --body "$(cat <<'EOF'
   <corps rempli basé sur pull_request_template.md>
   EOF
   )"

Directives du corps de PR

Basées sur .github/pull_request_template.md :

Section Summary

• Décrire ce que la PR fait
• Expliquer comment tester les modifications
• Inclure des captures d'écran/vidéos pour les modifications UI

Section Related Links

• Lier au ticket Linear : https://linear.app/n8n/issue/[TICKET-ID]
• Lier aux issues GitHub en utilisant des mots-clés pour fermer automatiquement :
  • closes #123 / fixes #123 / resolves #123
• Lier aux posts du forum Community si applicable

Checklist

Tous les éléments doivent être adressés avant la fusion :

• L'auteur humain de la PR a coché « I have seen this code, I have run this code, and I take responsibility for this code. »
• Le titre de PR suit les conventions
• Docs mises à jour ou ticket de suivi créé
• Tests inclus (les bugs nécessitent des tests de régression, les features nécessitent une couverture)
• Label release/backport ajouté si un correctif urgent doit être rétroporté

Exemples

Feature dans l'éditeur

feat(editor): Add workflow performance metrics display

Bug fix dans le core

fix(core): Resolve memory leak in execution engine

Modification spécifique à un nœud

fix(Slack Node): Handle rate limiting in message send

Breaking change (ajouter un point d'exclamation avant les deux-points)

feat(API)!: Remove deprecated v1 endpoints

Sans entrée changelog

refactor(core): Simplify error handling (no-changelog)

Sans scope (affecte plusieurs domaines)

chore: Update dependencies to latest versions

Validation

Le titre de PR doit correspondre à ce motif :

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

Règles de validation clés :

• Le type doit être un des types autorisés
• Le scope est optionnel mais doit être entre parenthèses s'il est présent
• Le point d'exclamation pour les breaking changes va avant les deux-points
• Le résumé doit commencer par une majuscule
• Le résumé ne doit pas se terminer par un point

Section Plan

Si un fichier de plan correspondant a été trouvé dans .claude/plans/ et que l'utilisateur a approuvé son inclusion, ajouter une section repliable à la fin du corps de PR (après la checklist, avant EOF) :

<details>
<summary>Implementation plan</summary>

<!-- contenu du fichier plan à coller ici -->

</details>

Correctifs de sécurité

Ce repository est public. Ne jamais exposer le vecteur d'attaque dans aucun artefact public. Décrire ce que le code fait, pas la menace qu'il prévient.

Avant de pousser un correctif de sécurité, vérifier : aucun nom de branche, commit, titre de PR, corps de PR, URL Linear, nom de test, ou commentaire de code ne fait allusion à la vulnérabilité.

En cas de doute, vérifier l'issue Linear pour les précautions supplémentaires possibles