Een codehost verbinden

Control Center werkt met drie codehosts, die in de hele app forges heten: GitHub, GitLab en Bitbucket Cloud. Geen van de drie is de standaard. Verbind er één en alles werkt; verbind er meerdere en één werkruimte kan tegelijk repo’s van alle drie bevatten.

De forge is een eigenschap van elke repo, uitgelezen uit de origin-remote wanneer je die registreert. Je kiest er nooit een, en er is geen instelling per werkruimte die je fout kunt zetten.

Een forge verbinden

Open Instellingen → Werkruimte → Profiel en identiteit (/settings/workspace/profile).
Zoek de kaart Codehosting. Elke ondersteunde forge staat erin, verbonden of niet.
Druk op Inloggen met … als de rij die optie biedt, of op Token toevoegen en plak er een.

Inloggen verschijnt voor een forge waarvoor je server een app geregistreerd heeft — vandaag is dat GitHub, via een deviceflow (zie De GitHub App maken). Al het andere is een geplakt token: het eerlijke aanbod in plaats van een knop die niet kan afronden.

Hoe dan ook zijn de inloggegevens van jou en staan ze op de server, gekoppeld aan je gebruikers-id: er wordt geen token opgeslagen op de machine waarop je hem hebt ingevoerd, elk apparaat waarop je inlogt gebruikt hetzelfde token, en geen ander lid kan het lezen. Ze gaan in bij de volgende aanvraag — er valt niets te herstarten, en loskoppelen stopt het versturen onmiddellijk.

Elke rij vertelt waar de inloggegevens vandaan komen, want dat is het verschil tussen “mijn token werkt niet” en “een ander token antwoordt”:

Ondertitel	Betekenis
`Ingelogd als octocat`	Je eigen inloggegevens worden gebruikt
`Ingelogd als octocat · via de app van deze server`	De app-identiteit van de server antwoordt — je bent niet ingelogd
`Ingelogd als octocat · uit de omgeving`	Een omgevingsvariabele van de server antwoordt, niet je inloggegevens
`Niet verbonden`	Je hebt geen inloggegevens voor deze forge

Welk token elke forge nodig heeft

Forge	Token	Waar je hem aanmaakt
GitHub	Klassiek: `repo` en `read:org`. Fijnmazig: Contents + Pull requests (lezen/schrijven), Checks + Actions (lezen)	github.com → Settings → Developer settings → Tokens
GitLab	Een persoonlijk toegangstoken met `api`	gitlab.com → User settings → Access tokens
Bitbucket	Een Atlassian API-token, plus je account-e-mailadres	id.atlassian.com → Security → API tokens

Bitbucket authenticeert met je account-e-mailadres als gebruikersnaam en het token als wachtwoord. Zet BITBUCKET_EMAIL in de serveromgeving, zodat duidelijk is welk e-mailadres bij het token hoort.

Of gebruik de omgeving

Voor een headless installatie of een CI-installatie leest de server deze:

GitHub — GITHUB_TOKEN, dan GH_TOKEN
GitLab — GITLAB_TOKEN, dan CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, dan BITBUCKET_TOKEN (met BITBUCKET_EMAIL)

Dit zijn de inloggegevens van de server, niet die van jou, en dat onderscheid is essentieel: een aanvraag die namens jou wordt gedaan, gebruikt jouw inloggegevens en niets anders, dus de omgeving neemt het nooit stilletjes van je over. Werk zonder mens erachter — webhooks, PR-polling, ticketsynchronisatie — bepaalt eerst de app-identiteit van de server, dan de inloggegevens van de eigenaar van de server, dan de omgeving. Die volgorde ligt vast, zodat “ik heb me ingelogd en er is niets veranderd” nooit een uitkomst kan zijn.

Je bent een ander persoon op elke forge

Dezelfde persoon is octocat op GitHub en iets heel anders op GitLab. Control Center bepaalt je identiteit per forge en gebruikt de juiste voor elke repo; daardoor kloppen “vraagt om mijn review”, “door mij gemaakt” en “jij hebt dit goedgekeurd” in een gemengde werkruimte.

Als de identiteit voor een forge niet is bepaald, dragen de repo’s ervan niets bij aan het postvak in plaats van alles te matchen. Het postvak zegt dat, in plaats van te beweren dat je helemaal bij bent.

Één postvak, elke forge

Het postvak en de PR-wachtrij waaieren uit over elke forge die in de werkruimte voorkomt en voegen de resultaten samen tot één stroom — een GitHub-pull request en een Bitbucket-pull request staan naast elkaar, geordend op tijd in plaats van gegroepeerd per leverancier.

Storingen blijven geïsoleerd. Een forge die platligt, tegen een limiet is aangelopen of niet verbonden is, draagt niets bij en laat de andere ongemoeid; hij maakt nooit het hele postvak leeg. De eigen repo’s blijven hun laatst bekende status tonen tot hij weer werkt.

Wat elke forge kan

Elke forge ondersteunt de kernlus: pull requests tonen en openen, diffs lezen, inline en op het hoogste niveau reageren, reviewen, mergen en sluiten. Daarbuiten verschillen ze echt van elkaar, en Control Center verbergt wat een forge niet kan in plaats van een bediening te tonen die stilletjes faalt.

Mogelijkheid	GitHub	GitLab	Bitbucket
Gebundelde reviews (in wachtrij)	✓	✓	—
Wijzigingen aanvragen	✓	✓	✓
Status “bekeken” per bestand gesynchroniseerd	✓	—	—
Emoji-reacties	✓	✓	—
Team-/groepsreviewers	✓	✓	—
Voorgestelde reviewers	✓	—	✓
CI-resultaten op een PR	✓	✓	✓
Inzoomen op de stappen/logs van een CI-job	✓	✓	—
Gestapelde pull requests	✓	—	—
Sjablonen voor PR-beschrijvingen	✓	✓	—
Meldingen pollen	✓	—	—
Uitgebreide gebruikersprofielen	✓	✓	—
PR-headref aan de serverzijde	✓	✓	—

Waar een mogelijkheid ontbreekt, verslechtert de functie op een eerlijke manier:

Bekeken-status werkt nog steeds, maar alleen op het apparaat waarop je hem instelt.
Gebundelde reviews op Bitbucket plaatsen opmerking na opmerking, dus reviewers zien ze afzonderlijk binnenkomen in plaats van allemaal tegelijk.
Geen PR-headref op Bitbucket betekent dat het uitchecken van een pull request de bronbranch op naam ophaalt; dat mislukt zodra die branch is verwijderd.

Terminologie

GitLab noemt een pull request een merge request. Control Center zegt in zijn eigen model overal “pull request”, en gebruikt het eigen woord van elke forge waar het over die forge gaat.

Problemen oplossen

De PR-lijst is leeg en zegt dat een forge niet verbonden is

Je hebt geen inloggegevens voor die forge. Log in of plak een token in Instellingen → Werkruimte → Profiel en identiteit → Codehosting. De repo’s van andere forges blijven onaangetast.

Ik heb een forge verbonden, maar de repo’s tonen nog niets

Controleer de ondertitel van de rij. Staat daar “via de app van deze server” of “uit de omgeving”, dan antwoorden andere inloggegevens dan je verwachtte — voor alles wat jij opvraagt, winnen je eigen inloggegevens, dus als er iets anders staat, zijn die van jou niet opgeslagen.

Een repo laat zich niet registreren

Registratie vereist alle drie: het pad ligt binnen een git-worktree, er is een origin-remote, en die remote wijst naar github.com, gitlab.com of bitbucket.org. Zie Repos toevoegen aan een werkruimte.

Alles stopt een tijdje na zwaar gebruik

Dat is de circuit breaker voor limieten. Een forge die zijn primaire limiet meldt, zorgt dat de client verdere aanvragen lokaal laat mislukken, zonder netwerkoproep, tot het venster is verstreken — zo kan een storm van herhaalpogingen de limiet niet verzwaren. Tijdelijke fouten worden opnieuw geprobeerd met exponentiële backoff.