Připojte hostitele kódu

Control Center pracuje se třemi hostiteli kódu. Aplikace jim říká forge: GitHub, GitLab a Bitbucket Cloud. Žádný není výchozí. Připoj jednoho a všechno funguje. Připoj jich víc a jeden pracovní prostor může držet repozitáře ze všech najednou.

Forge je vlastnost každého repozitáře. Přečte se z jeho remote origin při registraci. Nikdy ji nevybíráš a není nastavení na úrovni pracovního prostoru, ve kterém by ses spletl.

Připoj forge

Otevři Nastavení → Pracovní prostor → Profil a identita (/settings/workspace/profile).
Najdi kartu Hostování kódu. Jsou na ní všechny podporované forge, připojené i nepřipojené.
Stiskni Přihlásit se přes …, když to řádek nabízí, nebo Přidat token a token vlož.

Přihlásit se se ukáže u forge, pro kterou má server zaregistrovanou aplikaci. Dnes je to GitHub, přes device flow (viz Vytvořte GitHub App). Všechno ostatní je vložený token. To je poctivé ovládání: tlačítko, které by nešlo dokončit, se neukáže.

V obou případech je přihlašovací údaj tvůj a žije na serveru, klíčovaný tvým uživatelským id. Token se neukládá na stroj, na kterém jsi ho zadal, každé zařízení, ze kterého se přihlásíš, používá ten samý a žádný jiný člen ho nepřečte. Začne platit u dalšího požadavku. Není co restartovat a odpojení ho přestane posílat hned.

Každý řádek říká, odkud jeho přihlašovací údaj pochází. To je rozdíl mezi „můj token nefunguje“ a „odpovídá jiný token“:

Podtitul	Význam
`Signed in as octocat`	Používá se tvůj vlastní přihlašovací údaj
`Signed in as octocat · via this server's app`	Odpovídá identita aplikace serveru. Ještě ses nepřihlásil
`Signed in as octocat · from the environment`	Odpovídá proměnná prostředí serveru, ne tvůj přihlašovací údaj
`Not connected`	Pro tuhle forge nemáš přihlašovací údaj

Jaký token která forge chce

Forge	Token	Kde ho vytvořit
GitHub	Klasický: `repo` a `read:org`. Fine-grained: Contents + Pull requests (čtení/zápis), Checks + Actions (čtení)	github.com → Settings → Developer settings → Tokens
GitLab	Osobní přístupový token s oprávněním `api`	gitlab.com → User settings → Access tokens
Bitbucket	API token Atlassianu a e-mail účtu	id.atlassian.com → Security → API tokens

Bitbucket se ověřuje e-mailem účtu jako uživatelským jménem a tokenem jako heslem. Nastav BITBUCKET_EMAIL v prostředí serveru, aby věděl, který e-mail k tokenu patří.

Nebo použij prostředí

U instalace bez rozhraní nebo v CI server čte tohle:

GitHub — GITHUB_TOKEN, potom GH_TOKEN
GitLab — GITLAB_TOKEN, potom CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN, potom BITBUCKET_TOKEN (s BITBUCKET_EMAIL)

Tohle je přihlašovací údaj serveru, ne tvůj, a právě ten rozdíl rozhoduje. Požadavek tvým jménem použije tvůj údaj a nic jiného, takže tě prostředí nikdy potichu nezastoupí. Práce, za kterou nestojí člověk (webhooky, polling pull requestů, synchronizace ticketů), bere nejdřív identitu aplikace serveru, potom přihlašovací údaj vlastníka serveru a potom prostředí. Pořadí je pevné, aby „přihlásil jsem se a nic se nezměnilo“ nikdy nebylo podporované chování.

Na každé forge jsi někdo jiný

Stejný člověk je na GitHubu octocat a na GitLabu někdo úplně jiný. Control Center rozliší identitu u každé forge a u každého repozitáře použije tu správnou. Díky tomu v namíchaném pracovním prostoru sedí „Potřebuje vaši kontrolu“, „Vytvořeno mnou“ a „schválil jsi to“.

Když se identita u forge ještě nerozpoznala, její repozitáře do doručené pošty nepřidají nic, místo aby se shodovaly se vším. Doručená pošta to řekne a netvrdí, že „Máte všechno přečtené“.

Jedna doručená pošta, všechny forge

Doručená pošta a fronta PR se rozběhnou přes každou forge zastoupenou v pracovním prostoru a výsledky složí do jednoho proudu. Pull request z GitHubu a pull request z Bitbucketu stojí vedle sebe, seřazené časem, ne podle dodavatele.

Selhání jsou oddělená. Forge, která je nedostupná, narazila na limit požadavků, nebo není připojená, nepřispěje ničím a ostatní nechá být. Celou doručenou poštu nikdy nevyprázdní. Její repozitáře dál ukazují poslední známý stav, dokud se nevzpamatuje.

Co která forge umí

Každá forge umí základní smyčku: vypsat a otevřít pull requesty, číst diffy, komentovat v řádku i nad celým požadavkem, revidovat, sloučit a zavřít. Dál se opravdu liší. Control Center schová, co forge neumí, místo prvku, který potichu selže.

Schopnost	GitHub	GitLab	Bitbucket
Dávkové (neodeslané) revize	✓	✓	—
Vyžádat změny	✓	✓	✓
Synchronizace stavu „zhlédnuto“ u souboru	✓	—	—
Reakce emoji	✓	✓	—
Recenzenti z týmu nebo skupiny	✓	✓	—
Navržení recenzenti	✓	—	✓
Výsledky CI na PR	✓	✓	✓
Rozkliknutí kroků a logů úlohy CI	✓	✓	—
Naskládané pull requesty	✓	—	—
Šablony popisu PR	✓	✓	—
Polling oznámení	✓	—	—
Podrobné uživatelské profily	✓	✓	—
Head ref pull requestu na serveru	✓	✓	—

Kde schopnost chybí, funkce ustoupí bez předstírání:

Stav „zhlédnuto“ pořád funguje, ale jen na zařízení, na kterém jsi ho nastavil.
Dávkové revize na Bitbucketu se publikují komentář po komentáři, takže je recenzenti vidí přicházet po jednom, ne najednou.
Chybějící head ref na Bitbucketu znamená, že checkout pull requestu stáhne zdrojovou větev podle jména, a to selže, jakmile je větev smazaná.

Slovník

GitLab říká pull requestu merge request. Control Center ve vlastním modelu říká „pull request“ a tam, kde mluví o dané forge, použije její vlastní podstatné jméno.

Řešení problémů

Seznam PR je prázdný a hlásí, že forge není připojená

Pro tuhle forge nemáš přihlašovací údaj. Přihlas se, nebo vlož token v Nastavení → Pracovní prostor → Profil a identita → Hostování kódu. Repozitáře ostatních forge to nezasáhne.

Připojil jsem forge, ale její repozitáře pořád nic neukazují

Podívej se na podtitul řádku. Když v něm stojí „přes aplikaci tohoto serveru“ nebo „z prostředí“, odpovídá jiný přihlašovací údaj, než čekáš. Tvůj vlastní vyhrává u všeho, o co požádáš, takže když řádek říká něco jiného, ten tvůj se neuložil.

Repozitář nejde zaregistrovat

Registrace potřebuje všechny tři věci: cesta leží v git work tree, ten má remote origin a ten remote míří na github.com, gitlab.com nebo bitbucket.org. Viz Přidejte repozitáře do pracovního prostoru.

Po velkém zatížení všechno na chvíli přestane fungovat

To je jistič limitu požadavků. Když forge ohlásí svůj hlavní limit, klient další požadavky odmítne místně, bez volání po síti, dokud okno nevyprší. Vlna opakování tak limit ještě neprohloubí. Přechodné chyby se zkoušejí znovu s exponenciálně rostoucím odstupem.