Koble til en kodevert

Control Center støtter tre kodeverter, kalt forger i hele appen: GitHub, GitLab og Bitbucket Cloud. Ingen av dem er standardvalget. Koble til én, og alt fungerer; koble til flere, og ett enkelt arbeidsområde kan romme repoer fra alle samtidig.

Forgen er en egenskap ved hvert repo, lest fra origin-remoteen når du registrerer det. Du velger aldri én, og det finnes ingen innstilling per arbeidsområde å gjøre feil.

Koble til en forge

Åpne Innstillinger → Arbeidsområde → Profil og identitet (/settings/workspace/profile).
Finn kortet Kodehosting. Alle forger som støttes, er listet opp, tilkoblet eller ikke.
Trykk Logg inn med … hvis raden tilbyr det, eller Legg til token og lim inn ett.

Logg inn vises for en forge serveren din har en registrert app for — i dag gjelder det GitHub, via en device-flyt (se Opprett GitHub App). Alt annet er et innlimt token, som er den ærlige og tydelige løsningen i stedet for en knapp som ikke kan fullføres.

Uansett er påloggingsinformasjonen din og ligger på serveren, knyttet til bruker-ID-en din: ingen token lagres på maskinen der du skrev den inn, hver enhet du logger inn fra, bruker den samme, og ingen andre medlemmer kan lese den. Den trer i kraft ved neste forespørsel — det er ingenting å starte på nytt, og å koble fra stopper sendingen umiddelbart.

Hver rad forteller hvor påloggingsinformasjonen kom fra, fordi det er forskjellen mellom «tokenet mitt fungerer ikke» og «et annet token svarer»:

Undertekst	Betydning
`Logget inn som octocat`	Din egen påloggingsinformasjon brukes
`Logget inn som octocat · via denne serverens app`	Serverens appidentitet svarer — du er ikke logget inn
`Logget inn som octocat · fra miljøet`	En miljøvariabel på serveren svarer, ikke påloggingsinformasjonen din
`Ikke tilkoblet`	Du har ingen påloggingsinformasjon for denne forgen

Hvilket token hver forge vil ha

Forge	Token	Hvor du oppretter det
GitHub	Klassisk: `repo` og `read:org`. Finkornet: Contents + Pull requests (read/write), Checks + Actions (read)	github.com → Settings → Developer settings → Tokens
GitLab	Et personlig tilgangstoken med `api`	gitlab.com → User settings → Access tokens
Bitbucket	Et Atlassian-API-token, pluss e-postadressen til kontoen din	id.atlassian.com → Security → API tokens

Bitbucket autentiserer med e-postadressen til kontoen din som brukernavn og tokenet som passord. Sett BITBUCKET_EMAIL i servermiljøet, slik at den vet hvilken e-postadresse som skal kobles til tokenet.

Eller bruk miljøet

For en headless- eller CI-installasjon leser serveren disse:

GitHub — GITHUB_TOKEN, deretter GH_TOKEN
GitLab — GITLAB_TOKEN, deretter CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, deretter BITBUCKET_TOKEN (med BITBUCKET_EMAIL)

Dette er serverens påloggingsinformasjon, ikke din, og skillet er avgjørende: en forespørsel som gjøres på dine vegne, bruker din påloggingsinformasjon og ingenting annet, så miljøet trer aldri stille inn i stedet for deg. Arbeid uten et menneske bak — webhooks, PR-polling, sakssynk — bruker først serverens appidentitet, deretter servereierens påloggingsinformasjon, så miljøet. Rekkefølgen er fast, slik at «jeg logget inn, og ingenting endret seg» aldri er et gyldig utfall.

Du er en annen person hos hver forge

Det samme mennesket er octocat på GitHub og noe helt annet på GitLab. Control Center fastslår identiteten din per forge og bruker den riktige for hvert repo, og det er dette som gjør «trenger min gjennomgang», «opprettet av meg» og «du godkjente dette» riktige i et blandet arbeidsområde.

Hvis identiteten din hos en forge ikke er fastslått, bidrar repoene derfra med ingenting i innboksen i stedet for å matche alt. Innboksen sier fra om det i stedet for å påstå at du har full oversikt.

Én innboks, alle forger

Innboksen og PR-køen grener ut over alle forger som er representert i arbeidsområdet, og fletter resultatene sammen til én strøm — en GitHub-pull request og en Bitbucket-pull request ligger ved siden av hverandre, ordnet etter tid i stedet for gruppert etter leverandør.

Feil er isolert. En forge som er nede, har nådd en hastighetsgrense eller ikke er tilkoblet, bidrar med ingenting og lar de andre være i fred; den tømmer aldri hele innboksen. Repoene dens fortsetter å vise sist kjente tilstand til den er tilbake.

Hva hver forge kan gjøre

Alle forger støtter kjerneflyten: å liste opp og åpne pull requests, lese differ, kommentere i linjen og på toppnivå, gjennomgå, slå sammen og lukke. Utover det er de genuint forskjellige, og Control Center skjuler det en forge ikke kan gjøre, i stedet for å vise en kontroll som feiler i stillhet.

Egenskap	GitHub	GitLab	Bitbucket
Samlede (ventende) gjennomganger	✓	✓	—
Be om endringer	✓	✓	✓
«Sett»-status per fil synkronisert	✓	—	—
Emoji-reaksjoner	✓	✓	—
Team-/gruppereviewere	✓	✓	—
Foreslåtte reviewere	✓	—	✓
CI-resultater på en PR	✓	✓	✓
Gå i dybden på steg/logger for en CI-jobb	✓	✓	—
Stablede pull requests	✓	—	—
Maler for PR-beskrivelse	✓	✓	—
Polling av varsler	✓	—	—
Rike brukerprofiler	✓	✓	—
PR-head-ref på serversiden	✓	✓	—

Der en egenskap mangler, degraderes funksjonen på en ærlig måte:

Sett-status fungerer fortsatt, men bare på enheten der du satte den.
Samlede gjennomganger på Bitbucket publiseres kommentar for kommentar, så reviewerene ser dem komme enkeltvis i stedet for alle på én gang.
Ingen PR-head-ref på Bitbucket betyr at utsjekking av en pull request henter kildegrenen etter navn, noe som feiler når grenen er slettet.

Ordliste

GitLab kaller en pull request for en merge request. Control Center sier «pull request» i hele sin egen modell, og bruker hver forges eget ord der den snakker om den forgen.

Feilsøking

PR-listen er tom og sier at en forge ikke er tilkoblet

Du har ingen påloggingsinformasjon for den forgen. Logg inn eller lim inn et token i Innstillinger → Arbeidsområde → Profil og identitet → Kodehosting. Repoer fra andre forger påvirkes ikke.

Jeg koblet til en forge, men repoene viser fortsatt ingenting

Sjekk underteksten på raden. Hvis den sier «via denne serverens app» eller «fra miljøet», er det en annen påloggingsinformasjon som svarer enn den du forventet — din egen påloggingsinformasjon vinner for alt du ber om, så hvis den sier noe annet, ble ikke din lagret.

Et repo vil ikke registreres

Registrering krever alle tre: stien ligger inne i et git-worktree, den har en origin-remote, og den remote-en peker på github.com, gitlab.com eller bitbucket.org. Se Legg til repoer i et arbeidsområde.

Alt slutter å fungere en stund etter tung bruk

Det er kretsbryteren for hastighetsgrenser. En forge som signaliserer sin primære grense, får klienten til å avvise videre forespørsler lokalt, uten et nettverkskall, til vinduet er ute — slik at en storm av nye forsøk ikke kan forverre grensen. Forbigående feil prøves på nytt med eksponentiell backoff.