Intégration GitHub n8nAutomatiser GitHub avec n8n.

Commite un nouveau fichier dans le dépôt. Le contenu vient soit d'un texte saisi, soit d'un champ binaire produit par un nœud précédent : un PDF généré suit donc exactement le même chemin qu'une page Markdown.

• File Path : le chemin complet dans le dépôt, du genre docs/README.md, et pas seulement le nom du fichier.
• Binary File : c'est l'aiguillage. Décoché, n8n prend File Content ; coché, il prend le fichier posé dans Input Binary Field.
• Commit Message : la ligne qui apparaît dans l'historique du dépôt, autant qu'elle dise quel workflow a écrit.

Retire un fichier du dépôt et enregistre la suppression comme un commit, au même titre que n'importe quelle modification.

• File Path : le chemin complet du fichier à supprimer ; quand il vient d'un nœud précédent, une expression comme {{ $json.filePath }} évite de l'écrire en dur.
• Commit Message : requis ici aussi, et seule explication que gardera l'historique.

Écrit un nouveau contenu par-dessus un fichier existant et commite le résultat. Deux sources possibles comme à la création, texte ou binaire, avec une différence qui compte : le fichier doit déjà être là.

• File Path : désigne le fichier à modifier, chemin complet depuis la racine du dépôt, docs/README.md plutôt que README.md.
• File Content : le nouveau texte, en général construit par le nœud juste avant.
• Binary File et Input Binary Field : l'autre voie, quand la nouvelle version arrive en binaire.
• Commit Message : obligatoire.

Va chercher un fichier précis et le passe au nœud suivant. Par défaut tu récupères la réponse brute de l'API ; active As Binary Property et le fichier arrive en binaire, prêt à être joint à un e-mail ou renvoyé ailleurs.

• File Path : le chemin complet du fichier à lire.
• Put Output File in Field : le nom du champ binaire de sortie qui portera le fichier.
• Reference, dans Additional Parameters : un nom de commit, de branche ou de tag. Laissé vide, GitHub lit la branche par défaut du dépôt, souvent master.

Énumère le contenu d'un dossier, un item par entrée. C'est comme ça qu'un workflow boucle sur un répertoire dont il ne connaît pas le contenu à l'avance.

• File Path : le dossier à lire, donné en chemin complet depuis la racine du dépôt ; le champ porte le même libellé que dans les autres opérations sur les fichiers.

Ouvre un ticket dans le dépôt et le renvoie, avec le numéro que réclameront toutes les opérations suivantes sur ce ticket.

• Title : le seul champ requis, et la ligne que les gens lisent dans la liste des tickets.
• Body : optionnel, et en pratique l'endroit où atterrissent le message d'erreur, le contenu reçu ou le lien qui justifie le ticket.
• Assignees : une collection de noms d'utilisateurs. La collection Labels ajoute un Label et un Assignee dès la création.

Publie un commentaire sous un ticket existant. Rien d'autre ne bouge : le ticket garde son état, ses labels et ses assignés.

• Issue Number : un numéro, pas un titre. Récupère-le de l'étape qui a créé ou lu le ticket plutôt que de le taper à la main.
• Body : le texte du commentaire, souvent un résultat que le workflow vient de calculer.

Met à jour un ticket déjà ouvert. Tout ce qui est modifiable vit dans la collection Edit Fields, et tu n'ajoutes que les champs que tu veux vraiment toucher.

• Issue Number : le ticket à modifier.
• State : open ou closed, avec State Reason qui accepte completed, not_planned ou reopened.
• Labels, Assignees, Title, Body : le reste de la collection, pour réorienter ou réécrire.

Consulte un ticket et ses données, sans effet sur le dépôt. C'est l'étape de lecture qu'on place devant une décision : regarder l'état, regarder les labels, puis choisir la branche du workflow.

• Issue Number : le numéro du ticket à lire.

Verrouille la conversation d'un ticket, ce qui empêche le fil de récolter de nouveaux commentaires.

• Issue Number : le ticket à verrouiller.
• Lock Reason : off-topic, too heated, resolved ou spam. Le motif accompagne le verrouillage, ce qui évite d'écrire un commentaire pour l'expliquer.

Un appel, et toute l'organisation ressort en liste : un item par dépôt, donc une boucle possible sur un compte que personne n'a envie d'inventorier à la main.

• Return All : coché, n8n enchaîne les pages de l'API jusqu'au bout de l'organisation ; décoché, il s'arrête à Limit.
• Limit : le nombre maximal de dépôts renvoyés tant que Return All reste décoché.

Renvoie les personnes qui appartiennent à une organisation, un item par membre. Même bascule de pagination que pour les dépôts, braquée sur une question très différente : qui a les accès.

• Return All : laissé décoché, n8n renvoie jusqu'à Limit membres et s'arrête là ; coché, il parcourt tout l'effectif.

Crée une release sur un tag. Elle peut sortir publiée tout de suite, ou attendre en brouillon le temps que quelqu'un relise les notes.

• Tag : le tag de la release, seul champ requis.
• Name et Body, dans Additional Fields : le titre de la release et ses notes.
• Draft garde la release non publiée, Prerelease la marque comme non prête pour la production.
• Target Commitish : la branche ou le SHA de commit depuis lequel le tag est créé. Inutilisé si le tag existe déjà, et laissé vide il retombe sur la branche par défaut, souvent master.

Supprime une release, identifiée par son ID. Il n'y a rien d'autre à remplir, ce qui en fait aussi l'opération à vérifier deux fois avant d'activer le workflow.

• Release ID : l'identifiant de la release, ni son tag ni son nom. Il vient d'une étape de listage comme Get Many.

Va chercher une release et renvoie ses données, sans rien changer au passage. C'est l'étape qui donne au workflow le nom et les notes d'une release quand il n'a reçu qu'un identifiant.

• Release ID : la release à lire, transmise par une étape Get Many ou par l'opération qui l'a créée quelques nœuds plus tôt.

Ramène les releases d'un dépôt. Utile quand le workflow a besoin de l'historique et pas seulement de la dernière version.

• Return All : coché, n8n parcourt tout l'historique des releases ; décoché, il s'arrête à Limit.
• Limit : le nombre de releases renvoyées quand Return All est décoché.

Modifie une release qui existe déjà, que ce soit ses notes, son nom, son tag ou son statut.

• Release ID : la release à mettre à jour.
• Draft : passé à false, la release devient publiée. C'est comme ça que se termine une publication en deux temps.
• Body, Name, Tag Name, Prerelease et Target Commitish : le reste des Additional Fields.

Aucun paramètre à remplir ici. L'opération rend les données que GitHub garde sur un dépôt, ce qui en fait une première étape peu coûteuse : un workflow qui s'apprête à écrire des fichiers ou à ouvrir des tickets lit d'abord le dépôt, et s'arrête tout de suite si la réponse ne correspond pas à ce qu'il attendait.

Sort les tickets d'un dépôt avec les mêmes filtres que la liste GitHub.

• State : open, closed ou all.
• Labels : plusieurs labels d'un coup, séparés par une virgule.
• Updated Since : ne garde que les tickets mis à jour à partir de cette date.
• Assignee, Creator, Mentioned : restreignent par personne.
• Sort et Direction : created, updated ou comments, en ordre croissant ou décroissant.
• Return All : décoché, l'exécution s'arrête à Limit.

Si GitHub a détecté une licence dans le dépôt, cette opération en renvoie le contenu. Elle ne prend aucun paramètre, donc elle se branche directement après une étape de listage et répond dépôt après dépôt. Rien de détecté veut dire rien à lire, et ce silence est déjà une information.

Lit le profil communautaire d'un dépôt : métriques, score de santé, description, licence et le reste de ce que GitHub mesure à cet endroit. Aucun paramètre à régler, donc l'ajouter à un workflow ne coûte quasiment rien.

Un workflow de revue qui tourne à heure fixe plutôt que sur événement commence ici, avec les pull requests d'un dépôt ramenées sous forme d'items.

• State : open, closed ou all.
• Sort : created, updated, popularity par nombre de commentaires, ou long-running, qui ne garde que les pull requests ouvertes depuis plus d'un mois et actives sur le dernier mois.
• Limit : plafonné à 100, le maximum accepté par l'API pour cette liste.

Celle-ci donne les 10 chemins de contenu les plus consultés d'un dépôt sur les 14 derniers jours. Pas de filtre, pas de plage de dates : la fenêtre est figée, donc une vue plus longue n'existe que si le workflow stocke chaque exécution quelque part.

Même fenêtre figée, autre question : les 10 premiers domaines référents d'un dépôt sur les 14 derniers jours, autrement dit d'où viennent les visiteurs. Pas de paramètre non plus, et la même conséquence, l'historique t'appartient.

Cette opération publie une revue sur une pull request ouverte, verdict compris, ce qu'un commentaire ne fait pas.

• PR Number : le numéro de la pull request à relire, saisi ou repris d'un nœud précédent par une expression, {{ $json.champ }}.
• Event : le verdict, approve, requestChanges, comment ou pending ; en pending, la revue reste à soumettre à la main.
• Body : le texte de la revue, exigé par GitHub quand l'Event est Request Change ou Comment.
• Commit ID, dans Additional Fields : le SHA du commit à relire si ce n'est pas le dernier.

Une seule revue revient ici, celle dont l'identifiant est fourni, sur la pull request indiquée.

• PR Number : la pull request qui porte la revue.
• Review ID : l'identifiant de la revue à lire ; garde celui que renvoie l'opération Create, sinon tu n'auras pas de quoi la retrouver plus tard.

Toutes les revues d'une même pull request ressortent, un item par revue.

• PR Number : la pull request dont on déroule l'historique de revues.
• Return All : activé, n8n enchaîne les pages de l'API GitHub jusqu'à la dernière revue ; désactivé, il s'arrête au nombre fixé par Limit.
• Limit : le nombre maximal de revues rapportées tant que Return All reste décoché.

Seul le texte d'une revue existante bouge : le nœud n'expose que le champ Body pour cette opération.

• PR Number : la pull request concernée.
• Review ID : la revue à réécrire, le même identifiant que pour la lire.
• Body : le nouveau texte, qui remplace l'ancien.

Le nœud sort la liste des dépôts de l'utilisateur, un item par dépôt. Aucun identifiant à renseigner : il n'y a que la pagination à régler.

• Return All : activé, le nœud réclame la page suivante jusqu'au dernier dépôt ; désactivé, il s'arrête plus tôt.
• Limit : combien de dépôts rapporter tant que Return All est décoché.

Les issues assignées à l'utilisateur arrivent dans le workflow, et la collection Filters réduit le tas avant qu'il n'encombre les nœuds suivants.

• State : open, closed ou all.
• Labels : un ou plusieurs libellés séparés par des virgules.
• Updated Since : une date et une heure ; seules les issues mises à jour à partir de ce moment passent.
• Sort et Direction : tri par created, updated ou comments, en ordre croissant ou décroissant.
• Mentioned : ne garde que les issues où un utilisateur donné a été mentionné.

L'invitation part par email vers l'organisation nommée dans le nœud, sans passer par la page des membres.

• Organization : l'organisation GitHub qui reçoit la personne invitée.
• Email : son adresse, au format que le champ montre en exemple, name@email.com.

Un workflow du dépôt passe hors service et y reste jusqu'à ce que l'opération Enable le rallume. Attention au mot : il s'agit du workflow du dépôt GitHub, pas du workflow n8n qui l'entoure.

• Workflow : celui qu'on éteint, choisi dans le champ du même nom.

Un ordre de dispatch lance le job à la demande, et n8n rend la main tout de suite : l'exécution n'attend pas la fin du traitement.

• Workflow : celui à déclencher.
• Ref : la référence git utilisée, un nom de branche ou de tag, de quoi lancer le même workflow sur une branche de test ou sur un tag de version.
• Inputs : un objet JSON qui porte les paramètres d'entrée attendus par le workflow.

Le départ est le même qu'avec Dispatch, la suite non : l'exécution n8n se met en pause et attend un webhook, c'est-à-dire une URL appelée de l'extérieur, avant de passer au nœud suivant.

• Workflow : celui à lancer.
• Ref : le nom de la branche ou du tag sur lequel il tourne.
• Inputs : un objet JSON lu par le job, pratique pour transmettre un numéro de version ou une cible.

Remettre en route un workflow mis en pause tient en un appel : ses propres déclencheurs repartent aussitôt.

• Workflow : celui à réactiver, sélectionné comme pour Disable.

Le nœud lit un workflow du dépôt et le renvoie en un seul item. C'est le moyen le plus rapide de vérifier qu'un identifiant pointe bien là où tu crois.

• Workflow : celui à consulter.

L'usage enregistré par GitHub pour un workflow sort ici. C'est le chiffre à surveiller quand un dépôt consomme plus vite que prévu.

• Workflow : celui dont on demande l'usage.

Aucun paramètre à remplir : l'opération renvoie les workflows sous forme d'items, un par workflow, prêts à passer dans une boucle. C'est la porte d'entrée quand les identifiants ne sont pas connus d'avance.