GitHub
L'intégration GitHub donne à vos pipelines une lecture de l'activité de développement : commits, pull requests, revues, et exécutions GitHub Actions — par dépôt et par développeur. Elle est en lecture seule : rien n'est écrit sur vos dépôts.
Ce que vous pouvez en faire
- Rapport de production d'équipe — qui a livré quoi sur la période : commits, lignes ajoutées / supprimées, PR ouvertes et mergées, nombre de revues.
- Santé de la CI — nombre d'exécutions GitHub Actions réussies, en échec et en cours, par dépôt.
- Alimenter un agent — un agent qui synthétise la semaine technique (voir Cas d'usage → CTO IA).
Connexion
Dans Paramètres → Services → GitHub, onglet Comptes, deux méthodes :
- Se connecter avec GitHub — OAuth via l'application de la plateforme (quand l'opérateur l'a configurée), puis sélection des dépôts à suivre. Aucun token à copier.
- Coller un token (BYO) — un token d'accès GitHub en lecture (idéalement un fine-grained PAT limité aux dépôts concernés), la liste des dépôts à suivre (
owner/repo) et, pour GitHub Enterprise, une base d'API. Le token est stocké côté serveur et jamais réaffiché.
Le nœud github_report
Le nœud github_report récupère l'activité sur une fenêtre de temps (24h, 7d ou 30d) et la publie dans le contexte : ventilation par développeur (by_developer) et par dépôt (by_repo), journal des commits (commit_log), totaux, synthèse CI (ci), et la liste des dépôts qui n'ont pas pu être lus (unreadable_repos). Un agent en aval la transforme en compte rendu lisible.
Les lectures sont lancées en parallèle (avec une borne) sur les dépôts, pour rester rapide sur une organisation GitHub fournie.
Tools d'agent (lecture) : github.report, github.list_commits, github.list_pull_requests.
Bonnes pratiques
- Préférez un token dédié à l'intégration plutôt qu'un token personnel partagé.
- Restreignez les portées au strict nécessaire (lecture des dépôts, des pull requests, des actions).
- Combinez avec le canal Planification pour un rapport récurrent (ex. tous les soirs à 18h).