Nastavte integraci GitHub

Tenhle návod bere ty části nastavení, které patří ke GitHubu. GitHub je jeden ze tří podporovaných hostitelů kódu. Jak připojit GitLab nebo Bitbucket a jak je pracovní prostor míchá, je v Připojte hostitele kódu.

Než začneš

Účet na GitHubu s přístupem k repozitářům, na kterých chceš pracovat
Buď GitHub App zaregistrovaná pro tvůj server (viz Vytvořte GitHub App), abys se mohl přihlásit, nebo osobní přístupový token s repo a read:org k vložení

Přihlas se přes GitHub

Device flow: GitHub ti ukáže krátký kód, ty ho schválíš na github.com a server dostane přihlašovací údaj. Žádná callback URL, žádný port, nic k vystavení. Je k dispozici, kdykoli má server client id, což oficiální build už obsahuje.

Jdi do Nastavení → Pracovní prostor → Profil a identita → Hostování kódu (nebo na první krok onboardingu)
Na řádku GitHub klikni na Přihlásit se přes GitHub
Dialog ukáže osmiznakový kód a v prohlížeči otevře github.com/login/device. Kód už máš ve schránce
Vlož ho, schval aplikaci a vrať se. Řádek se sám přepne na „Přihlášeno jako tvoje-uživatelské-jméno.“

Dialog můžeš zavřít, než to v prohlížeči dokončíš. Server se dál ptá, dokud kód nevyprší (asi 15 minut), takže přihlášení stejně dorazí.

Nebo vlož token

Záloha pro případ, kdy server nemá aplikaci, kdy aplikace není nainstalovaná na účtu, který potřebuješ, nebo kdy prostě chceš použít PAT.

Jdi do Nastavení → Pracovní prostor → Profil a identita → Hostování kódu
Na řádku GitHub klikni na Přidat token
Vlož token s repo a read:org (classic) a ulož ho. Token fine-grained potřebuje u repozitáře Contents a Pull requests (read and write) a k tomu Checks a Actions (read).

Token se při uložení ověří, takže řádek umí pojmenovat účet, ke kterému patří. Odeber ho kliknutím na Odpojit.

Kontrolní bod: řádek GitHub ukazuje „Přihlášeno jako tvoje-uživatelské-jméno.“. Když odpovídající přihlašovací údaj není tvůj, přípona pojmenuje zdroj: „přes aplikaci tohoto serveru“ nebo „z prostředí“.

Co ti integrace dá

Funkce	Jak
Seznam a detail PR	GitHub REST API, ze serveru, na identitě aplikace nebo na tvém přihlašovacím údaji
Běhy kontrol	GitHub Checks API
Publikování revize	Krok vázaný na uživatele, který odešle tvoji revizi do PR
Registrace repozitáře	Checkout se přijme, když remote `origin` míří na github.com, nebo na gitlab.com / bitbucket.org
Přístup agenta ke GitHubu	Broker přihlašovacích údajů vloží token jen pro čtení jako `GH_TOKEN` / `GITHUB_TOKEN`; push jde přes Control Center
Upozornění	Dotazování na doručenou poštu oznámení GitHubu na serveru vyvolá „Zmíněn v pull requestu“ a „Vyžádána kontrola“
Profily uživatelů	Karty profilu při najetí a filtrování PR podle autora

Některé cesty použijí GraphQL API místo REST tam, kde je to levnější: aktivita větví pro výběr při sestavování PR a živý stav revize, podle kterého se pozná, jestli oznámení „Vyžádána kontrola“ pořád čeká.

Sleduj výpadky GitHubu

V záhlaví se objeví stavový čip, když některý poskytovatel hlásí problémy. Týká se GitHubu, Claude, OpenAI a Kimi. Dokud je všechno v pořádku, je schovaný. Jeho přítomnost znamená potíž.

Klikni na čip a otevře se panel Stav služeb se stavem každého poskytovatele a tlačítkem Obnovit. Stavy se samy obnoví každé dvě minuty.

Jak agenti na GitHubu jednají

Agent, který pracuje ve worktree GitHubu, dostane vždycky token GitHub jen pro čtení. Push jde přes Control Center, které se zeptá pravidla Odeslat na remote a pak ho předá se zapisovacím tokenem, který agent nikdy nedrží. Viz Nastavte politiky sandboxu
Commity, které agent udělá, jsou autorované jako agent: zobrazované jméno plus (agent), na syntetické adrese klíčované id agenta, nikdy jako člověk. Člověk, který o to požádal, je uvedený v trailerech Co-Authored-By
Když je nakonfigurovaná GitHub App, broker při každém spuštění vystaví úzce vymezené instalační tokeny vázané na repozitář, platné zhruba hodinu, místo aby předal široký token. Instalace se určí podle vlastníka repozitáře daného běhu, takže jedna aplikace nainstalovaná na několika účtech se správně omezí na účet, kterého se běh dotkne. Bez aplikace agenti dostanou token z prostředí, který nejde omezit jen na čtení: pravidlo pro push pak váže git push, ale ne kód, který token používá přímo
Token je vždycky ten od brokera, nikdy vlastní token člena, který o běh požádal. Token serveru se odepře běhu, který jedná za člena, jenž není vlastník a nemá připojený GitHub

Řešení potíží

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

Na tomhle serveru nemáš přihlašovací údaj ke GitHubu. Přihlas se nebo vlož token v Hostování kódu. Repozitáře na jiných forge to nezasáhne. Nic nepřispívá jen GitHub.

Řádek nabízí „Přidat token“, ale ne „Přihlásit se přes GitHub“

Server nemá client id. U buildu ze zdrojového kódu je to běžný stav, protože přihlašovací údaje se zapékají jen do oficiálních buildů. Viz Vytvořte GitHub App: zabere to asi dvě minuty a udělat to musí jen vlastník serveru, a to jednou.

Dialog přihlášení hlásí, že poskytovatel nevrátil device code

GitHub App existuje, ale zaškrtnutí Device flow je vypnuté. Zapni ho v nastavení aplikace (General → Device flow) a zkus to znovu.

Řádek hlásí „přes aplikaci tohoto serveru“, a já čekám vlastní účet

Nepřihlásil ses. To, co vidíš, je identita aplikace serveru, která odpovídá. Na tom řádku klikni na Přihlásit se přes GitHub.

Fine-grained PAT neukáže tlačítko sloučení ani stav kontrol

Token potřebuje Contents a Pull requests (read and write) a k tomu Checks a Actions (read). Po změně ho znovu vlož v Hostování kódu.

Přidání repozitáře se odmítne

Registrace vyžaduje všechny tři podmínky: cesta leží uvnitř git work tree, má remote origin a ten remote míří na podporovanou forge (github.com, gitlab.com nebo bitbucket.org). Viz Přidejte repozitáře do pracovního prostoru.

Po velké zátěži na chvíli přestane fungovat všechno

To je jistič limitu požadavků. GitHub oznamuje primární limit kódem 403 s hlavičkou x-ratelimit-remaining: 0 a časem obnovení. Jakmile takovou odpověď uvidí, klient další požadavky odmítne lokálně, bez volání po síti, dokud okno nevyprší, aby opakované pokusy limit ještě neprohloubily. Přechodné chyby se zkusí znovu nejvýš třikrát, s exponenciální prodlevou, a drží se retry-after.