Vytváření úložišť GitHub Enterprise Serveru

Služby Azure DevOps

Místní GitHub Enterprise Server můžete integrovat se službou Azure Pipelines. Místní server může být přístupný z internetu nebo nemusí být.

Pokud je váš GitHub Enterprise Server dostupný ze serverů, na kterých běží služba Azure Pipelines, postupujte takto:

• Můžete nastavit klasické kanály buildu a YAML.
• můžete nakonfigurovat aktivační události CI, PR a plánované aktivační události.

Pokud váš GitHub Enterprise Server není dostupný ze serverů, na kterých běží služba Azure Pipelines, postupujte takto:

• Můžete nastavit jenom klasické kanály buildu.
• Ruční nebo naplánované buildy můžete spustit pouze
• Nemůžete nastavit kanály YAML.
• Pro klasické kanály buildu nemůžete nakonfigurovat triggery CI nebo PR.

Pokud je váš místní server dostupný z agentů hostovaných Microsoftem, můžete je použít ke spuštění kanálů. Jinak musíte nastavit agenty v místním prostředí, které mají přístup k místnímu serveru a načíst kód.

Dostupný ze služby Azure Pipelines

První věc, kterou je potřeba zkontrolovat, je, jestli je váš GitHub Enterprise Server dostupný ze služby Azure Pipelines.

1. V uživatelském rozhraní Azure DevOps přejděte do nastavení projektu a v části Kanály vyberte Připojení služeb.
2. Vyberte Nové připojení služby a jako typ připojení zvolte GitHub Enterprise Server .
3. Zadejte požadované informace pro vytvoření připojení k serveru GitHub Enterprise.
4. Na panelu připojení služby vyberte Ověřit .

Pokud ověření projde, servery, na kterých běží služba Azure Pipelines, se můžou spojit s místním Serverem GitHub Enterprise. Můžete pokračovat a nastavit připojení. Toto připojení služby pak můžete použít při vytváření klasického kanálu buildu nebo KANÁLU YAML. Pro kanál můžete také nakonfigurovat triggery CI a PR. Většina funkcí v Azure Pipelines, které pracují s GitHubem, fungují také s GitHub Enterprise Serverem. Projděte si dokumentaci k GitHubu a seznamte se s těmito funkcemi. Tady jsou některé rozdíly:

• Integrace mezi GitHubem a Azure Pipelines je jednodušší prostřednictvím aplikace Azure Pipelines na marketplace GitHubu. Tato aplikace umožňuje nastavit integraci bez nutnosti spoléhat se na token OAuth konkrétního uživatele. Nemáme podobnou aplikaci, která funguje s GitHub Enterprise Serverem. Proto musíte použít PAT, uživatelské jméno a heslo nebo OAuth k nastavení připojení mezi Azure Pipelines a serverem GitHub Enterprise.
• Azure Pipelines podporuje řadu funkcí zabezpečení GitHubu k ověření příspěvků z externích forků. Například tajné kódy uložené v kanálu nejsou dostupné spuštěné úloze. Tyto ochrany nejsou při práci se serverem GitHub Enterprise dostupné.
• Triggery komentářů nejsou dostupné na serveru GitHub Enterprise. K aktivaci kanálu nemůžete použít komentáře v žádosti o přijetí změn na serveru GitHub Enterprise.
• Kontroly GitHubu nejsou dostupné na serveru GitHub Enterprise. Všechny aktualizace stavu jsou prostřednictvím základních stavů.

Nedostupné z Azure Pipelines

Pokud ověření připojení GitHub Enterprise Serveru, jak je vysvětleno v předchozí části, selže, Azure Pipelines nemůže komunikovat s vaším serverem. Příčinou je pravděpodobně nastavení podnikové sítě. Brána firewall ve vaší síti může například bránit externímu provozu v přístupu k vašim serverům. V tomto případě máte dvě možnosti:

• Ve spolupráci s IT oddělením otevřete síťovou cestu mezi Azure Pipelines a GitHub Enterprise Serverem. Do pravidel brány firewall můžete například přidat výjimky, které umožňují průchod provozu ze služby Azure Pipelines. V části IP adresy Azure DevOps zjistíte, které IP adresy je potřeba povolit. Kromě toho musíte mít veřejnou položku DNS pro GitHub Enterprise Server, aby služba Azure Pipelines přeložil plně kvalifikovaný název domény vašeho serveru na IP adresu. Při všech těchto změnách se pokuste vytvořit a ověřit připojení GitHub Enterprise Serveru v Azure Pipelines.

• Místo připojení k GitHubu Enterprise Serveru můžete použít jiné připojení Gitu . Nezapomeňte zrušit zaškrtnutí políčka Pro pokus o přístup k tomuto serveru Git ze služby Azure Pipelines. S tímto typem připojení můžete nakonfigurovat pouze klasický kanál buildu. Triggery CI a PR nebudou v této konfiguraci fungovat. Můžete spustit pouze ruční nebo naplánovaná spuštění kanálu.

Dostupný od agentů hostovaných Microsoftem

Dalším rozhodnutím, které možná musíte udělat, je, jestli ke spuštění kanálů použít agenty hostované Microsoftem nebo agenty v místním prostředí. Často dochází k tomu, jestli se agenti hostovaní Microsoftem dostanou k vašemu serveru. Pokud chcete zkontrolovat, jestli je to možné, vytvořte jednoduchý kanál pro použití agentů hostovaných Microsoftem a nezapomeňte přidat krok pro kontrolu zdrojového kódu ze serveru. Pokud to projde, můžete dál používat agenty hostované Microsoftem.

Nedostupné z agentů hostovaných Microsoftem

Pokud jednoduchý testovací kanál uvedený v předchozí části selže s chybou TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, pak GitHub Enterprise Server není dostupný z agentů hostovaných Microsoftem. To je pravděpodobně způsobeno bránou firewall blokující provoz z těchto serverů. V tomto případě máte dvě možnosti:

• Ve spolupráci s IT oddělením otevřete síťovou cestu mezi agenty hostovanými Microsoftem a Serverem GitHub Enterprise. Přečtěte si část o sítích v agentech hostovaných Microsoftem.

• Přepněte na používání agentů v místním prostředí nebo agentů škálovací sady. Tyto agenty je možné nastavit v rámci vaší sítě, a proto budou mít přístup k Serveru GitHub Enterprise. Tito agenti vyžadují pouze odchozí připojení ke službě Azure Pipelines. Pro příchozí připojení není potřeba otevřít bránu firewall. Ujistěte se, že název serveru, který jste zadali při vytváření připojení k GitHub Enterprise Serveru, je možné přeložit z agentů v místním prostředí.

IP adresy Azure DevOps

Azure Pipelines odesílá požadavky na GitHub Enterprise Server do:

• Dotaz na seznam úložišť během vytváření kanálu (klasické kanály a kanály YAML)
• Vyhledání existujících souborů YAML během vytváření kanálu (kanály YAML)
• Vrácení souborů YAML se změnami (kanály YAML)
• Registrace webhooku během vytváření kanálu (klasické kanály a kanály YAML)
• Prezentace editoru pro soubory YAML (kanály YAML)
• Řešení šablon a rozšíření souborů YAML před spuštěním (kanály YAML)
• Zkontrolujte, jestli od posledního naplánovaného spuštění nedošlo k nějakým změnám (klasické kanály a kanály YAML).
• Načtení podrobností o nejnovějším potvrzení a zobrazení v uživatelském rozhraní (klasické kanály a kanály YAML)

Můžete si všimnout, že kanály YAML zásadně vyžadují komunikaci mezi Azure Pipelines a GitHub Enterprise Serverem. Proto není možné nastavit kanál YAML, pokud GitHub Enterprise Server není viditelný pro Azure Pipelines.

Když k nastavení klasického kanálu použijete jiné připojení Gitu , zakažte komunikaci mezi službou Azure Pipelines a GitHub Enterprise Serverem a použijete k sestavení kódu agenty v místním prostředí, budete mít snížený výkon:

• Během vytváření kanálu budete muset zadat název úložiště ručně.
• Triggery CI nebo PR nemůžete použít, protože Azure Pipelines nemůže zaregistrovat webhook na GitHub Enterprise Serveru.
• Naplánované triggery s možností sestavení nelze použít pouze v případech, kdy dojde ke změnám.
• V uživatelském rozhraní nelze zobrazit informace o nejnovějším potvrzení.

Pokud chcete nastavit kanály YAML nebo chcete vylepšit prostředí klasickými kanály, je důležité povolit komunikaci z Azure Pipelines na GitHub Enterprise Server.

Pokud chcete povolit provoz z Azure DevOps pro přístup k vašemu Serveru GitHub Enterprise, přidejte IP adresy nebo značky služeb zadané v příchozích připojeních do seznamu povolených bran firewall. Pokud používáte ExpressRoute, nezapomeňte do seznamu povolených adres brány firewall zahrnout také rozsahy IP adres ExpressRoute.

Omezení

• Pro dosažení nejlepšího výkonu doporučujeme v jednom úložišti maximálně 50 kanálů. Pro přijatelný výkon doporučujeme maximálně 100 kanálů v jednom úložišti. Doba potřebná ke zpracování nasdílení změn do úložiště se zvyšuje s počtem kanálů v daném úložišti. Kdykoli se do úložiště nasdílí oznámení, Azure Pipelines musí načíst všechny kanály YAML v daném úložišti, aby zjistili, jestli některý z nich musí běžet, a načtení každého kanálu způsobuje snížení výkonu. Kromě problémů s výkonem může příliš mnoho kanálů v jednom úložišti vést k omezování na straně GitHubu, protože Azure Pipelines může za krátkou dobu provádět příliš mnoho požadavků.

• Použití rozšíření a zahrnutí šablon do kanálu ovlivňuje rychlost, s jakou Azure Pipelines vytváří požadavky rozhraní API GitHubu a může vést k omezování na straně GitHubu. Před spuštěním kanálu musí Azure Pipelines vygenerovat kompletní kód YAML, takže musí načíst všechny soubory šablon.

• Azure Pipelines načte z úložiště maximálně 2000 větví do rozevíracích seznamů na portálu Azure DevOps, například v okně Vybrat větev pro výchozí větev pro nastavení ručních a plánovaných sestavení nebo při ručním výběru větve při spuštění kanálu.

  Pokud požadovanou větev v seznamu nevidíte, zadejte název požadované větve ručně do výchozí větve pro ruční a plánované pole sestavení .

  Pokud kliknete na tři tečky a otevřete dialogové okno Vybrat větev a zavřete ji bez výběru platné větve z rozevíracího seznamu, může se zobrazit zpráva Některá nastavení vyžadují pozornost a toto nastavení je povinné pod výchozí větví pro ruční a plánované sestavení. Pokud chcete tuto zprávu obejít, znovu otevřete kanál a zadejte název přímo do výchozí větve pro pole ručních a plánovaných sestavení.

Často kladené dotazy

Problémy související s integrací GitHub Enterprise spadají do následujících kategorií:

• Triggery, které selhávají: Kanál se neaktivuje, když do úložiště nasdílím aktualizaci.
• Neúspěšná rezervace: Kanál se aktivuje, ale v kroku rezervace selže.
• Nesprávná verze: Kanál se spustí, ale používá neočekávanou verzi zdrojového nebo YAML.

Neúspěšné triggery

Právě jsem vytvořil nový kanál YAML s triggery CI/PR, ale kanál se neaktivuje.

Při řešení potíží se selháním triggerů postupujte následovně:

• Přepisují se triggery CI nebo PR YAML nastavením kanálu v uživatelském rozhraní? Při úpravě kanálu zvolte ... a pak Triggery.

  

  Zkontrolujte nastavení Přepsat trigger YAML odsud pro typy triggeru (kontinuální integrace nebo ověření žádosti o přijetí změn) dostupné pro vaše úložiště.

  

• Webhooky se používají ke komunikaci aktualizací z GitHubu Enterprise do Azure Pipelines. V GitHubu Enterprise přejděte do nastavení úložiště a pak do Webhooků. Ověřte, že webhooky existují. Obvykle byste měli vidět dva webhooky – push, pull_request. Pokud ne, musíte znovu vytvořit připojení služby a aktualizovat kanál tak, aby používal nové připojení služby.

• Vyberte všechny webhooky v GitHubu Enterprise a ověřte, že datová část odpovídající potvrzení uživatele existuje a byla úspěšně odeslána do Azure DevOps. Pokud událost nebylo možné sdělit Azure DevOps, může se zde zobrazit chyba.

• Když Azure Pipelines obdrží oznámení z GitHubu, pokusí se kontaktovat GitHub a načíst další informace o úložišti a souboru YAML. Pokud je GitHub Enterprise Server za bránou firewall, nemusí se tento provoz dostat na váš server. Projděte si IP adresy Azure DevOps a ověřte, že jste udělili výjimky všem požadovaným IP adresám. Tyto IP adresy se mohly změnit, protože jste původně nastavili pravidla výjimek.

• Je kanál pozastavený nebo zakázaný? Otevřete editor kanálu a pak vyberte Nastavení , které chcete zkontrolovat. Pokud je kanál pozastavený nebo zakázaný, triggery nefungují.

• Aktualizovali jste soubor YAML ve správné větvi? Pokud odešlete aktualizaci do větve, pak soubor YAML ve stejné větvi řídí chování CI. Pokud odešlete aktualizaci do zdrojové větve, pak soubor YAML, který je výsledkem sloučení zdrojové větve s cílovou větví, řídí chování žádosti o přijetí změn. Ujistěte se, že soubor YAML ve správné větvi má potřebnou konfiguraci CI nebo PR.

• Nakonfigurovali jste trigger správně? Při definování triggeru YAML můžete zadat klauzule include i exclude pro větve, značky a cesty. Ujistěte se, že klauzule include odpovídá podrobnostem potvrzení a že je klauzule exclude nevyloučí. Zkontrolujte syntaxi triggerů a ujistěte se, že je přesná.

• Použili jste proměnné při definování triggeru nebo cest? To není podporováno.

• Použili jste šablony pro váš soubor YAML? Pokud ano, ujistěte se, že jsou triggery definované v hlavním souboru YAML. Triggery definované v souborech šablon se nepodporují.

• Vyloučili jste větve nebo cesty, do kterých jste změny odeslali? Otestujte vložením změny do zahrnuté cesty v zahrnuté větvi. Všimněte si, že cesty v triggerech rozlišují malá a velká písmena. Při zadávání cest v triggerech se ujistěte, že používáte stejný případ jako u skutečných složek.

• Právě jste nasdílili novou větev? Pokud ano, nová větev nemusí spustit nové spuštění. Viz část Chování triggerů při vytváření nových větví.

Triggery CI nebo PR fungují správně. Ale teď přestali pracovat.

Nejprve si projděte kroky pro řešení potíží v předchozí otázce a pak postupujte následovně:

• Máte ve své žádosti o přijetí změn konflikty při slučování? V případě žádosti o přijetí změn, která neaktivovala kanál, otevřete ho a zkontrolujte, jestli došlo ke konfliktu při sloučení. Vyřešte konflikt při sloučení.

• Dochází ke zpoždění zpracování událostí nabízených oznámení nebo žádosti o přijetí změn? Zpoždění můžete obvykle ověřit tak, že zjistíte, jestli je problém specifický pro jeden kanál nebo je společný pro všechny kanály nebo úložiště v projektu. Pokud nabízené oznámení nebo aktualizace žádosti o přijetí změn do některého z úložišť tento příznak vykazuje, může docházet ke zpožděním při zpracování událostí aktualizace. Tady je několik důvodů, proč může docházet ke zpoždění:

  • Na naší stránce stavu dochází k výpadku služby. Pokud se na stránce stavu zobrazí problém, musí na ní náš tým už začít pracovat. Podívejte se na stránku, kde najdete časté aktualizace problému.
  • Vaše úložiště obsahuje příliš mnoho kanálů YAML. Pro dosažení nejlepšího výkonu doporučujeme v jednom úložišti maximálně 50 kanálů. Pro přijatelný výkon doporučujeme maximálně 100 kanálů v jednom úložišti. Čím více kanálů existuje, tím pomalejší je zpracování nabízeného oznámení do tohoto úložiště. Kdykoli se do úložiště nasdílí oznámení, azure Pipelines musí načíst všechny kanály YAML v daném úložišti, aby zjistily, jestli některý z nich musí běžet, a každý nový kanál má za následek snížení výkonu.
  • Vaše instance GitHub Enterprise Serveru může být nedostatečně zřízený a zpomaluje zpracování požadavků ze služby Azure Pipelines. Přečtěte si další informace o aspektech hardwaru pro GitHub Enterprise Server.

Neúspěšná rezervace

Používáte agenty hostované Microsoftem? Pokud ano, tito agenti se možná nebudou moct spojit s vaším Serverem GitHub Enterprise. Další informace najdete v tématu Nedostupné z agentů hostovaných Microsoftem.

Nesprávná verze

V kanálu se používá nesprávná verze souboru YAML. Proč?

• U triggerů CI se vyhodnocuje soubor YAML, který je ve větvi, kterou odesíláte, a zjistí, jestli se má spustit sestavení CI.
• U triggerů žádosti o přijetí změn se soubor YAML, který je výsledkem sloučení zdrojových a cílových větví žádosti o přijetí změn, vyhodnocuje, jestli se má spustit sestavení žádosti o přijetí změn.