Kódhoszt csatlakoztatása
A Control Center három kódhoszttal működik együtt, amelyeket az alkalmazás végig forge néven említ: GitHub, GitLab és Bitbucket Cloud. Egyik sem az alapértelmezett. Ha egyet csatlakoztat, minden működik; ha többet, egyetlen munkaterület egyszerre mindháromról tarthat repókat.
A forge minden repó tulajdonsága: regisztráláskor annak origin remote-jából olvassuk ki. Ezt soha nem kell kiválasztania, és nincs munkaterületenkénti beállítás, amit el lehetne rontani.
Forge csatlakoztatása
Szekció neve “Forge csatlakoztatása”- Nyissa meg a Beállítások → Munkaterület → Profil és identitás (
/settings/workspace/profile) oldalt. - Keresse meg a Kódtárhely kártyát. Minden támogatott forge szerepel rajta, akár csatlakoztatva van, akár nem.
- Nyomja meg a Bejelentkezés ezzel: … gombot, ha a sor felkínálja, vagy a Token hozzáadása gombot, és illesszen be egyet.
A Bejelentkezés azoknál a forge-oknál jelenik meg, amelyekhez a szerverének van regisztrált alkalmazása — ez ma a GitHub, eszközkódos folyamattal (lásd GitHub App létrehozása). Minden más esetben beillesztett tokenről van szó, ami az őszinte megoldás, nem pedig egy gomb, amely nem tud sikerrel járni.
Akár így, akár úgy, a hitelesítő adat az Öné, és a szerveren él, a felhasználói azonosítójához rendelve: nem tárolódik token azon a gépen, amelyre beírta, minden eszköz, amelyről bejelentkezik, ugyanazt használja, és más tag nem tudja kiolvasni. A következő kérésnél lép életbe — nincs mit újraindítani, a leválasztás pedig azonnal leállítja a küldését.
Minden sor megmondja, honnan származik a hitelesítő adata, mert ez a különbség aközött, hogy „nem működik a tokenem”, és aközött, hogy „egy másik token válaszol”:
| Felirat | Jelentés |
|---|---|
Bejelentkezve mint octocat |
A saját hitelesítő adata van használatban |
Bejelentkezve mint octocat · ennek a szervernek az alkalmazásán keresztül |
A szerver alkalmazásidentitása válaszol — Ön nincs bejelentkezve |
Bejelentkezve mint octocat · a környezetből |
Egy szerverkörnyezeti változó válaszol, nem az Ön hitelesítő adata |
Nincs csatlakoztatva |
Nincs hitelesítő adata ehhez a forge-hoz |
Milyen tokent vár el az egyes forge-ok
Szekció neve “Milyen tokent vár el az egyes forge-ok”| Forge | Token | Hol hozza létre |
|---|---|---|
| GitHub | Klasszikus: repo és read:org. Finomhangolt: Contents + Pull requests (read/write), Checks + Actions (read) |
github.com → Settings → Developer settings → Tokens |
| GitLab | Személyes hozzáférési token api jogosultsággal |
gitlab.com → User settings → Access tokens |
| Bitbucket | Atlassian API-token, valamint a fiókja e-mail-címe | id.atlassian.com → Security → API tokens |
A Bitbucket a fiókja e-mail-címét használja felhasználónévként, a tokent pedig jelszóként. Állítsa be a BITBUCKET_EMAIL változót a szerver környezetében, hogy tudja, melyik e-mail-címet párosítsa a tokenhez.
Vagy használja a környezetet
Szekció neve “Vagy használja a környezetet”Headless vagy CI-telepítés esetén a szerver ezeket olvassa:
- GitHub —
GITHUB_TOKEN, majdGH_TOKEN - GitLab —
GITLAB_TOKEN, majdCI_JOB_TOKEN - Bitbucket —
BITBUCKET_API_TOKEN, majdBITBUCKET_TOKEN(aBITBUCKET_EMAILváltozóval)
Ezek a szerver hitelesítő adatai, nem az Öné, és ez a megkülönböztetés döntő: az Ön nevében indított kérés az Ön hitelesítő adatát használja, és semmi mást, így a környezet soha nem lép csendben az Ön helyébe. Az ember nélkül futó munka — webhookok, PR-lekérdezés, jegyszinkronizálás — először a szerver alkalmazásidentitását oldja fel, aztán a szerver tulajdonosának hitelesítő adatát, végül a környezetet. A sorrend rögzített, hogy a „Bejelentkeztem, és semmi sem változott” soha ne legyen támogatott eredmény.
Ön minden forge-on más személy
Szekció neve “Ön minden forge-on más személy”Ugyanaz az ember a GitHubon octocat, a GitLabon pedig valami egészen más. A Control Center forge-onként oldja fel az identitását, és minden repóhoz a megfelelőt használja; ez teszi helyessé az „átnézésre vár”, az „én hoztam létre” és az „ezt Ön hagyta jóvá” megjelöléseket egy vegyes munkaterületen.
Ha egy forge identitása nem oldható fel, a repói semmivel sem járulnak hozzá a Beérkezetthez, ahelyett hogy mindenre illeszkednének. A Beérkezett ezt jelzi, ahelyett hogy azt állítaná, minden elolvasva.
Egy Beérkezett, minden forge
Szekció neve “Egy Beérkezett, minden forge”A Beérkezett és a PR-várólista szétágazik a munkaterületen képviselt minden forge-ra, és az eredményeket egyetlen folyamba vonja össze — egy GitHub pull request és egy Bitbucket pull request egymás mellett áll, idő szerint rendezve, nem szállító szerint csoportosítva.
A hibák elkülönülnek. Az a forge, amelyik leállt, sebességkorlátozás alá esik vagy nincs csatlakoztatva, semmivel sem járul hozzá, és a többit érintetlenül hagyja; soha nem üríti ki a teljes Beérkezettet. A saját repói továbbra is a legutóbb ismert állapotukat mutatják, amíg helyre nem áll.
Mire képes az egyes forge-ok
Szekció neve “Mire képes az egyes forge-ok”Minden forge támogatja az alapvető ciklust: a pull requestek listázása és megnyitása, a diffek olvasása, beágyazott és legfelső szintű megjegyzés írása, átnézés, összefésülés és lezárás. Azon túl azonban valóban különböznek, és a Control Center elrejti azt, amire egy forge nem képes, ahelyett hogy olyan vezérlőt mutatna, amely csendben meghibásodik.
| Képesség | GitHub | GitLab | Bitbucket |
|---|---|---|---|
| Kötegelt (függőben lévő) átnézések | ✓ | ✓ | — |
| Módosítás kérése | ✓ | ✓ | ✓ |
| Fájlonkénti „megtekintett” állapot szinkronizálva | ✓ | — | — |
| Emodzsi-reakciók | ✓ | ✓ | — |
| Csapat- vagy csoportátnézők | ✓ | ✓ | — |
| Javasolt átnézők | ✓ | — | ✓ |
| CI-eredmények egy PR-en | ✓ | ✓ | ✓ |
| Egy CI-feladat lépéseinek/naplóinak megtekintése | ✓ | ✓ | — |
| Halmozott pull requestek | ✓ | — | — |
| PR-leírássablonok | ✓ | ✓ | — |
| Értesítések lekérdezése | ✓ | — | — |
| Részletes felhasználói profilok | ✓ | ✓ | — |
| Szerveroldali PR head ref | ✓ | ✓ | — |
Ahol egy képesség hiányzik, a funkció korlátozottan, de őszintén működik:
- A megtekintett állapot továbbra is működik, de csak azon az eszközön, amelyen beállította.
- A kötegelt átnézések a Bitbucketnél megjegyzésenként küldődnek el, így az átnézők egyenként látják megérkezni őket, nem egyszerre.
- A Bitbucketnél nincs PR head ref, ezért egy pull request kivétele a forráságát név szerint hozza le, ami az ág törlése után meghiúsul.
Szóhasználat
Szekció neve “Szóhasználat”A GitLab a pull requestet merge requestnek hívja. A Control Center a saját modelljében végig „pull requestet” mond, és ott használja az adott forge saját szavát, ahol arról a forge-ról beszél.
Hibaelhárítás
Szekció neve “Hibaelhárítás”A PR-lista üres, és azt írja, hogy egy forge nincs csatlakoztatva
Szekció neve “A PR-lista üres, és azt írja, hogy egy forge nincs csatlakoztatva”Nincs hitelesítő adata ahhoz a forge-hoz. Jelentkezzen be, vagy illesszen be egy tokent a Beállítások → Munkaterület → Profil és identitás → Kódtárhely alatt. A többi forge repóit ez nem érinti.
Csatlakoztattam egy forge-ot, de a repói továbbra sem mutatnak semmit
Szekció neve “Csatlakoztattam egy forge-ot, de a repói továbbra sem mutatnak semmit”Ellenőrizze a sor feliratát. Ha az áll ott, hogy „ennek a szervernek az alkalmazásán keresztül” vagy „a környezetből”, akkor más hitelesítő adat válaszol, mint amire számított — bármit is kér, az Ön saját hitelesítő adata élvez elsőbbséget, tehát ha más szerepel, az Öné nem lett elmentve.
Egy repó nem regisztrálódik
Szekció neve “Egy repó nem regisztrálódik”A regisztrációhoz mindhárom kell: az útvonal egy git work tree-n belül van, van origin remote-ja, és az a remote a github.com, a gitlab.com vagy a bitbucket.org címre mutat. Lásd: Repók hozzáadása munkaterülethez.
Nagy használat után egy időre minden leáll
Szekció neve “Nagy használat után egy időre minden leáll”Ez a sebességkorlát áramkör-megszakítója. Ha egy forge jelzi az elsődleges korlátját, a kliens a további kéréseket helyben, hálózati hívás nélkül buktatja el, amíg az időablak le nem telik — így az újrapróbálkozások vihara nem mélyítheti el a korlátot. Az átmeneti hibákat exponenciális visszalépéssel próbálja újra.