Connecter un hébergeur de code

Control Center fonctionne avec trois hébergeurs de code, appelés forges dans toute l’application : GitHub, GitLab et Bitbucket Cloud. Aucun n’est celui par défaut. Connectez-en un et tout fonctionne ; connectez-en plusieurs et un même espace de travail peut réunir à la fois des dépôts des trois.

La forge est une propriété de chaque dépôt, lue depuis son dépôt distant origin au moment où vous l’enregistrez. Vous n’en choisissez jamais une, et aucun réglage par espace de travail ne peut être mal configuré.

Connecter une forge

Ouvrez Paramètres → Espace de travail → Profil et identité (/settings/workspace/profile).
Repérez la carte Hébergement de code. Toutes les forges prises en charge y figurent, connectées ou non.
Appuyez sur Se connecter avec … si la ligne le propose, ou sur Ajouter un jeton, puis collez-en un.

Se connecter apparaît pour une forge pour laquelle votre serveur a une application enregistrée — aujourd’hui, c’est GitHub, via un flux d’appareil (voir Créer la GitHub App). Tout le reste passe par un jeton collé, ce qui est l’affordance honnête plutôt qu’un bouton qui ne peut pas aboutir.

Dans un cas comme dans l’autre, l’identifiant est le vôtre et réside sur le serveur, indexé par votre ID utilisateur : aucun jeton n’est stocké sur la machine où vous l’avez saisi, tous les appareils depuis lesquels vous vous connectez utilisent le même, et aucun autre membre ne peut le lire. Il prend effet à la prochaine requête — il n’y a rien à redémarrer, et la déconnexion met fin immédiatement à son envoi.

Chaque ligne vous indique d’où vient son identifiant, car c’est la différence entre « mon jeton ne fonctionne pas » et « un autre jeton répond » :

Sous-titre	Signification
`Connecté en tant que octocat`	Votre propre identifiant est utilisé
`Connecté en tant que octocat · via l’application de ce serveur`	L’identité applicative du serveur répond — vous n’êtes pas connecté
`Connecté en tant que octocat · depuis l’environnement`	Une variable d’environnement du serveur répond, pas votre identifiant
`Non connecté`	Vous n’avez aucun identifiant pour cette forge

Le jeton que chaque forge demande

Forge	Jeton	Où le créer
GitHub	Classique : `repo` et `read:org`. À granularité fine : Contents + Pull requests (read/write), Checks + Actions (read)	github.com → Settings → Developer settings → Tokens
GitLab	Un jeton d’accès personnel avec `api`	gitlab.com → User settings → Access tokens
Bitbucket	Un jeton d’API Atlassian, plus l’adresse e-mail de votre compte	id.atlassian.com → Security → API tokens

Bitbucket s’authentifie avec l’adresse e-mail de votre compte comme nom d’utilisateur et le jeton comme mot de passe. Définissez BITBUCKET_EMAIL dans l’environnement du serveur pour qu’il sache quelle adresse e-mail associer au jeton.

Ou utiliser l’environnement

Pour une installation sans interface ou en CI, le serveur lit les suivantes :

GitHub — GITHUB_TOKEN, puis GH_TOKEN
GitLab — GITLAB_TOKEN, puis CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, puis BITBUCKET_TOKEN (avec BITBUCKET_EMAIL)

Ce sont les identifiants du serveur, et non les vôtres, et la distinction est déterminante : une requête faite en votre nom utilise votre identifiant et rien d’autre ; l’environnement ne vous remplace donc jamais discrètement. Le travail sans humain derrière — webhooks, interrogation des PR, synchronisation des tickets — résout d’abord l’identité applicative du serveur, puis l’identifiant du propriétaire du serveur, puis l’environnement. L’ordre est fixe, afin que « je me suis connecté et rien n’a changé » ne soit jamais un résultat pris en charge.

Vous êtes une personne différente sur chaque forge

Le même humain est octocat sur GitHub et tout autre chose sur GitLab. Control Center résout votre identité par forge et utilise la bonne pour chaque dépôt, ce qui rend exacts « à réviser », « créé par moi » et « vous avez approuvé ceci » dans un espace de travail mixte.

Si l’identité d’une forge n’est pas résolue, ses dépôts n’apportent rien à la boîte de réception plutôt que de tout faire correspondre. La boîte de réception le signale au lieu de prétendre que vous êtes à jour.

Une seule boîte de réception, toutes les forges

La boîte de réception et la file d’attente des PR se déploient sur chaque forge représentée dans l’espace de travail et fusionnent les résultats en un seul flux — une demande de tirage GitHub et une demande de tirage Bitbucket se côtoient, classées par heure plutôt que regroupées par fournisseur.

Les défaillances sont isolées. Une forge en panne, limitée en débit ou non connectée n’apporte rien et laisse les autres intactes ; elle ne vide jamais toute la boîte de réception. Ses propres dépôts continuent d’afficher leur dernier état connu jusqu’à son rétablissement.

Ce que chaque forge sait faire

Chaque forge prend en charge la boucle de base : lister et ouvrir des demandes de tirage, lire les diffs, commenter en ligne et au niveau général, réviser, fusionner et fermer. Au-delà, elles diffèrent réellement, et Control Center masque ce qu’une forge ne peut pas faire plutôt que d’afficher un contrôle qui échoue en silence.

Capacité	GitHub	GitLab	Bitbucket
Révisions groupées (en attente)	✓	✓	—
Demander des modifications	✓	✓	✓
État « vu » par fichier synchronisé	✓	—	—
Réactions emoji	✓	✓	—
Relecteurs d’équipe / de groupe	✓	✓	—
Relecteurs suggérés	✓	—	✓
Résultats de CI sur une PR	✓	✓	✓
Explorer les étapes et journaux d’une tâche de CI	✓	✓	—
Demandes de tirage empilées	✓	—	—
Modèles de description de PR	✓	✓	—
Interrogation des notifications	✓	—	—
Profils utilisateurs enrichis	✓	✓	—
Référence de tête de PR côté serveur	✓	✓	—

Là où une capacité manque, la fonction se dégrade honnêtement :

L’état « vu » fonctionne toujours, mais uniquement sur l’appareil où vous l’avez défini.
Les révisions groupées sur Bitbucket publient chaque commentaire séparément, de sorte que les relecteurs les voient arriver un à un plutôt que tous d’un coup.
L’absence de référence de tête de PR sur Bitbucket signifie que l’extraction d’une demande de tirage récupère sa branche source par son nom, ce qui échoue une fois cette branche supprimée.

Vocabulaire

GitLab appelle une demande de tirage une merge request. Control Center parle de « pull request » dans tout son propre modèle et emploie le nom propre à chaque forge lorsqu’il évoque celle-ci.

Dépannage

La liste des PR est vide et indique qu’une forge n’est pas connectée

Vous n’avez aucun identifiant pour cette forge. Connectez-vous ou collez un jeton dans Paramètres → Espace de travail → Profil et identité → Hébergement de code. Les dépôts des autres forges ne sont pas touchés.

J’ai connecté une forge, mais ses dépôts n’affichent toujours rien

Vérifiez le sous-titre de la ligne. S’il indique « via l’application de ce serveur » ou « depuis l’environnement », c’est un autre identifiant que celui attendu qui répond — votre propre identifiant l’emporte pour tout ce que vous demandez ; si le sous-titre dit autre chose, c’est que le vôtre n’a pas été enregistré.

Un dépôt refuse de s’enregistrer

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 github.com, gitlab.com ou bitbucket.org. Voir Ajouter des dépôts à un espace de travail.

Tout cesse de fonctionner un moment après un usage intensif

C’est le coupe-circuit de la limite de débit. Une forge qui signale sa limite principale fait échouer localement les requêtes suivantes du client, sans appel réseau, jusqu’à l’écoulement de la fenêtre — une tempête de nouvelles tentatives ne peut donc pas aggraver la limite. Les défaillances transitoires sont réessayées avec un délai exponentiel.