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 d’eux n’est celui par défaut. Connectez-en un et tout fonctionne ; connectez-en plusieurs et un même espace de travail peut contenir à la fois des dépôts des trois.

La forge est une propriété de chaque dépôt, lue dans son dépôt distant origin au moment où vous l’enregistrez. Vous n’en choisissez jamais une, et il n’existe aucun paramètre par espace de travail qu’on puisse mal configurer.

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 sont listées, connectées ou non.
Appuyez sur Se connecter avec … si la ligne l’offre, 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, au moyen d’un flux d’appareil (voir Créer la GitHub App). Tout le reste est 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 identifiant d’utilisateur : aucun jeton n’est stocké sur la machine où vous l’avez saisi, tous les appareils à partir desquels 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ù provient 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 le courriel de votre compte	id.atlassian.com → Security → API tokens

Bitbucket s’authentifie avec le courriel 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 quel courriel 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, de sorte que l’environnement ne vous remplace 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 quelqu’un de tout autre sur GitLab. Control Center résout votre identité par forge et utilise la bonne pour chaque dépôt, ce qui fait que « à réviser », « créé par moi » et « vous avez approuvé ceci » sont exacts dans un espace de travail mixte.

Si l’identité d’une forge n’est pas résolue, ses dépôts ne contribuent rien à la boîte de réception plutôt que de tout correspondre. La boîte de réception le dit, 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 ne contribue 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 peut 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 supérieur, 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 commentaire par commentaire, de sorte que les relecteurs les voient arriver individuellement plutôt que tous à la fois.
Aucune 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 nom, ce qui échoue une fois cette branche supprimée.

Vocabulaire

GitLab appelle une demande de tirage une merge request. Control Center dit « pull request » partout dans son propre modèle et emploie le nom propre à chaque forge lorsqu’il parle de cette forge.

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, donc si le sous-titre dit autre chose, 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.