Configurer l’intégration GitHub

Ce guide couvre les volets propres à GitHub de la configuration. GitHub est l’un des trois hébergeurs de code pris en charge — consultez Connecter un hébergeur de code pour connecter GitLab ou Bitbucket, et pour savoir comment un espace de travail les combine.

Prérequis

Un compte GitHub ayant accès aux dépôts sur lesquels vous voulez travailler
Soit une GitHub App enregistrée pour votre serveur (voir Créer la GitHub App) pour pouvoir vous connecter, soit un jeton d’accès personnel avec repo et read:org à coller

Se connecter avec GitHub

Un flux d’appareil : GitHub vous montre un code court, vous l’approuvez sur github.com, et le serveur reçoit l’identifiant — aucune URL de rappel, aucun port, rien à exposer. Disponible dès que le serveur dispose d’un identifiant client, ce qui est déjà le cas des versions officielles.

Allez dans Paramètres → Espace de travail → Profil et identité → Hébergement de code (ou à la première étape de la configuration initiale)
Sur la ligne GitHub, cliquez sur Se connecter avec GitHub
Une boîte de dialogue affiche un code de huit caractères et ouvre github.com/login/device dans votre navigateur. Le code est déjà dans votre presse-papiers
Collez-le, approuvez l’application, puis revenez. La ligne bascule d’elle-même à « Connecté en tant que votre-nom-d’utilisateur »

Vous pouvez fermer la boîte de dialogue pendant que vous terminez dans le navigateur — le serveur continue d’interroger GitHub jusqu’à l’expiration du code (environ 15 minutes), de sorte que la connexion aboutit quand même.

Ou coller un jeton

La solution de repli lorsque le serveur n’a pas d’application, lorsque l’application n’est pas installée sur un compte dont vous avez besoin, ou lorsque vous préférez simplement utiliser un PAT.

Allez dans Paramètres → Espace de travail → Profil et identité → Hébergement de code
Sur la ligne GitHub, cliquez sur Ajouter un jeton
Collez un jeton avec repo et read:org (classique) et enregistrez. Un jeton à granularité fine a besoin des autorisations Contents et Pull requests (lecture et écriture) sur le dépôt, plus Checks et Actions (lecture).

Le jeton est vérifié au moment où il est stocké, de sorte que la ligne peut nommer le compte auquel il appartient. Cliquez sur Déconnecter pour le supprimer.

Point de contrôle : la ligne GitHub affiche « Connecté en tant que votre-nom-d’utilisateur ». Un suffixe nomme la source lorsque l’identifiant qui répond n’est pas le vôtre — « via l’application de ce serveur » ou « depuis l’environnement ».

Ce que l’intégration vous apporte

Fonctionnalité	Comment
Liste et détail des PR	L’API REST de GitHub, depuis le serveur, sur l’identité d’application ou votre propre identifiant
Exécutions de vérification	L’API Checks de GitHub
Publication des révisions	Une étape nécessitant une action de l’utilisateur, qui publie votre révision dans la PR
Enregistrement des dépôts	Un checkout est accepté si son dépôt distant `origin` pointe vers github.com — ou vers gitlab.com / bitbucket.org
Accès des agents à GitHub	Le courtier d’identifiants injecte un jeton en lecture seule sous forme de `GH_TOKEN` / `GITHUB_TOKEN`; les poussées passent par Control Center
Notifications	Une interrogation côté serveur de votre boîte de réception GitHub déclenche « Mentionné dans une pull request » et « Revue demandée »
Profils d’utilisateur	Cartes de profil au survol et filtrage des PR par auteur

Certains chemins passent par l’API GraphQL plutôt que REST lorsqu’elle coûte moins cher — l’activité des branches pour le sélecteur de PR à composer et l’état de révision en direct qui détermine si une notification de révision demandée est toujours en attente.

Surveiller les pannes de GitHub

La barre de titre affiche une pastille d’état lorsqu’un fournisseur est dégradé, ce qui couvre GitHub, Claude, OpenAI et Kimi. Elle est masquée tant que tout va bien — c’est sa présence qui signale un problème, et non son absence.

Cliquez sur la pastille pour ouvrir un volet volant présentant l’état de chaque fournisseur et un bouton d’actualisation. Les états s’actualisent d’eux-mêmes toutes les deux minutes.

Savoir comment les agents agissent sur GitHub

Un agent qui travaille dans un arbre de travail GitHub reçoit toujours un jeton GitHub en lecture seule. Un push passe par Control Center, qui interroge la règle Pousser vers un dépôt distant puis le transmet avec un jeton d’écriture que l’agent ne détient jamais. Voir Configurer les politiques de bac à sable
Les commits créés par un agent sont signés en tant qu’agent — le nom affiché suivi de (agent), à une adresse synthétique indexée par l’ID de l’agent — jamais en tant qu’humain. La personne à l’origine de la demande est créditée par un trailer Co-Authored-By
Avec une GitHub App configurée, le courtier génère à chaque lancement des jetons d’installation à granularité fine, limités au dépôt et d’une durée d’environ une heure, au lieu de transmettre un jeton large. L’installation est résolue à partir du propriétaire du dépôt de l’exécution, de sorte qu’une application installée sur plusieurs comptes s’applique correctement à celui que l’exécution touche. Sans application, les agents reçoivent le jeton de l’environnement, qu’il est impossible de restreindre à la lecture seule : la règle de push contraint alors git push, mais pas le code qui utilise directement le jeton
Le jeton est toujours celui du courtier, jamais celui du membre demandeur. Le jeton du serveur est retenu pour une exécution qui agit pour un membre qui n’est pas propriétaire et n’a pas connecté GitHub

Dépannage

La liste des PR est vide et indique que GitHub n’est pas connecté

Vous n’avez aucun identifiant GitHub sur ce serveur. Connectez-vous ou collez un jeton sous Hébergement de code. Les dépôts sur d’autres hébergeurs ne sont pas touchés — seuls ceux de GitHub n’apportent rien.

La ligne propose « Ajouter un jeton » mais pas « Se connecter avec GitHub »

Le serveur n’a aucun identifiant client — ce qui est l’état normal d’une compilation à partir des sources, les identifiants n’étant intégrés qu’aux versions officielles. Voir Créer la GitHub App : cela prend environ deux minutes et seul le propriétaire du serveur doit le faire, une seule fois.

La boîte de dialogue de connexion indique que le fournisseur n’a renvoyé aucun code d’appareil

La GitHub App existe, mais sa case Device flow est désactivée. Activez-la dans les paramètres de l’application (General → Device flow), puis réessayez.

La ligne indique « via l’application de ce serveur » alors que je m’attendais à mon propre compte

Vous ne vous êtes pas connecté ; ce que vous voyez, c’est l’identité d’application du serveur qui répond. Cliquez sur Se connecter avec GitHub sur cette ligne.

Un PAT à granularité fine n’affiche ni bouton de fusion ni état des vérifications

Le jeton a besoin des autorisations Contents et Pull requests (lecture et écriture), ainsi que Checks et Actions (lecture). Après l’avoir modifié, collez-le de nouveau sous Hébergement de code.

L’ajout d’un dépôt est refusé

L’enregistrement exige les trois conditions suivantes : le chemin se trouve à l’intérieur d’un arbre de travail git, il possède un dépôt distant origin, et ce dépôt distant pointe vers un hébergeur pris en charge (github.com, gitlab.com ou bitbucket.org). Voir Ajouter des dépôts à un espace de travail.

Tout cesse de fonctionner pendant un certain temps après un usage intensif

C’est le coupe-circuit de limite de débit. GitHub signale sa limite principale par un 403 portant x-ratelimit-remaining: 0 et un moment de réinitialisation ; dès qu’il en voit un, le client fait échouer localement les requêtes suivantes sans appel réseau jusqu’à l’écoulement de la fenêtre, de sorte qu’une tempête de nouvelles tentatives ne peut pas aggraver la limite. Les défaillances transitoires sont réessayées jusqu’à trois fois avec un repli exponentiel, en tenant compte de retry-after.