Skapa GitHub Enterprise Server-lagringsplatser

  • Artikel

Azure DevOps Services

Du kan integrera din lokala GitHub Enterprise Server med Azure Pipelines. Din lokala server kan vara exponerad för Internet eller så kanske den inte är det.

Om din GitHub Enterprise Server kan nås från de servrar som kör Azure Pipelines-tjänsten:

  • du kan konfigurera klassiska bygg- och YAML-pipelines
  • du kan konfigurera CI, PR och schemalagda utlösare

Om din GitHub Enterprise Server inte kan nås från servrarna som kör Azure Pipelines-tjänsten:

  • du kan bara konfigurera klassiska byggpipelines
  • du kan bara starta manuella eller schemalagda versioner
  • du kan inte konfigurera YAML-pipelines
  • du kan inte konfigurera CI- eller PR-utlösare för dina klassiska byggpipelines

Om din lokala server kan nås från Microsoft-värdbaserade agenter kan du använda dem för att köra dina pipelines. Annars måste du konfigurera lokalt installerade agenter som kan komma åt din lokala server och hämta koden.

Kan nås från Azure Pipelines

Det första du bör kontrollera är om din GitHub Enterprise Server kan nås från Azure Pipelines-tjänsten.

  1. I ditt Azure DevOps-användargränssnitt går du till projektinställningarna och väljer Tjänstanslutningar under Pipelines.
  2. Välj Ny tjänstanslutning och välj GitHub Enterprise Server som anslutningstyp.
  3. Ange den information som krävs för att skapa en anslutning till din GitHub Enterprise Server.
  4. Välj Verifiera i panelen för tjänstanslutning.

Om verifieringen godkänns kan servrarna som kör Azure Pipelines-tjänsten nå din lokala GitHub Enterprise Server. Du kan fortsätta och konfigurera anslutningen. Sedan kan du använda den här tjänstanslutningen när du skapar en klassisk bygg- eller YAML-pipeline. Du kan också konfigurera CI- och PR-utlösare för pipelinen. De flesta funktioner i Azure Pipelines som fungerar med GitHub fungerar också med GitHub Enterprise Server. Läs dokumentationen för GitHub för att förstå de här funktionerna. Här är några skillnader:

  • Integreringen mellan GitHub och Azure Pipelines underlättas via en Azure Pipelines-app på GitHub Marketplace. Med den här appen kan du konfigurera en integrering utan att behöva förlita dig på en viss användares OAuth-token. Vi har ingen liknande app som fungerar med GitHub Enterprise Server. Du måste därför använda ett PAT, användarnamn och lösenord eller OAuth för att konfigurera anslutningen mellan Azure Pipelines och GitHub Enterprise-servern.
  • Azure Pipelines stöder ett antal GitHub-säkerhetsfunktioner för att verifiera bidrag från externa förgreningar. Hemligheter som lagras i en pipeline görs till exempel inte tillgängliga för ett jobb som körs. Dessa skydd är inte tillgängliga när du arbetar med GitHub Enterprise-servern.
  • Kommentarsutlösare är inte tillgängliga med GitHub Enterprise-servern. Du kan inte använda kommentarer i en Pull-begäran för GitHub Enterprise-serverrepo för att utlösa en pipeline.
  • GitHub-kontroller är inte tillgängliga på GitHub Enterprise-servern. Alla statusuppdateringar sker via grundläggande status.

Kan inte nås från Azure Pipelines

När verifieringen av en GitHub Enterprise Server-anslutning enligt beskrivningen i ovanstående avsnitt misslyckas kan Azure Pipelines inte kommunicera med servern. Detta beror troligen på hur företagsnätverket har konfigurerats. En brandvägg i nätverket kan till exempel förhindra att extern trafik når dina servrar. Du har två alternativ i det här fallet:

  • Arbeta med IT-avdelningen för att öppna en nätverkssökväg mellan Azure Pipelines och GitHub Enterprise Server. Du kan till exempel lägga till undantag i brandväggsreglerna så att trafik från Azure Pipelines kan flöda igenom. Se avsnittet om Azure DevOps-IP-adresser för att se vilka IP-adresser du behöver tillåta. Dessutom måste du ha en offentlig DNS-post för GitHub Enterprise Server så att Azure Pipelines kan matcha serverns fullständiga domännamn till en IP-adress. Med alla dessa ändringar försöker du skapa och verifiera en GitHub Enterprise Server-anslutning i Azure Pipelines.

  • I stället för att använda en GitHub Enterprise Server-anslutning kan du använda en annan Git-anslutning. Avmarkera alternativet försök att komma åt den här Git-servern från Azure Pipelines. Med den här anslutningstypen kan du bara konfigurera en klassisk bygg-pipeline. CI- och PR-utlösare fungerar inte i den här konfigurationen. Du kan bara starta manuella eller schemalagda pipelinekörningar.

Kan nås från Microsoft-värdbaserade agenter

Ett annat beslut du eventuellt måste fatta är om du ska använda Microsoft-värdbaserade agenter eller lokalt installerade agenter för att köra dina pipelines. Detta beror ofta på om Microsoft-värdbaserade agenter kan nå din server. Om du vill kontrollera om de kan kan du skapa en enkel pipeline för att använda Microsoft-värdbaserade agenter och se till att lägga till ett steg för att kolla in källkoden från servern. Om detta godkänns kan du fortsätta att använda Microsoft-värdbaserade agenter.

Kan inte nås från Microsoft-värdbaserade agenter

Om den enkla testpipeline som nämns i ovanstående avsnitt misslyckas med felet 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 attemptingkan GitHub Enterprise Server inte nås från Microsoft-värdbaserade agenter. Detta orsakas förmodligen igen av en brandvägg som blockerar trafik från dessa servrar. Du har två alternativ i det här fallet:

  • Arbeta med IT-avdelningen för att öppna en nätverkssökväg mellan Microsoft-värdbaserade agenter och GitHub Enterprise Server. Se avsnittet om nätverk i Microsoft-värdbaserade agenter.

  • Växla till att använda lokalt installerade agenter eller skalningsuppsättningsagenter. Dessa agenter kan konfigureras i nätverket och har därför åtkomst till GitHub Enterprise Server. Dessa agenter kräver endast utgående anslutningar till Azure Pipelines. Du behöver inte öppna en brandvägg för inkommande anslutningar. Kontrollera att namnet på den server som du angav när du skapade GitHub Enterprise Server-anslutningen kan matchas från de lokalt installerade agenterna.

Ip-adresser för Azure DevOps

Azure Pipelines skickar begäranden till GitHub Enterprise Server för att:

  • Fråga efter en lista över lagringsplatser när pipelinen skapas (klassiska och YAML-pipelines)
  • Leta efter befintliga YAML-filer när pipelinen skapas (YAML-pipelines)
  • Checka in YAML-filer (YAML-pipelines)
  • Registrera en webhook när pipelinen skapas (klassiska pipelines och YAML-pipelines)
  • Presentera en redigerare för YAML-filer (YAML-pipelines)
  • Lösa mallar och expandera YAML-filer före körning (YAML-pipelines)
  • Kontrollera om det finns några ändringar sedan den senaste schemalagda körningen (klassiska och YAML-pipelines)
  • Hämta information om den senaste incheckningen och visa den i användargränssnittet (klassiska och YAML-pipelines)

Du kan observera att YAML-pipelines i grunden kräver kommunikation mellan Azure Pipelines och GitHub Enterprise Server. Därför går det inte att konfigurera en YAML-pipeline om GitHub Enterprise Server inte är synlig för Azure Pipelines.

När du använder Annan Git-anslutning för att konfigurera en klassisk pipeline, inaktiverar kommunikationen mellan Azure Pipelines-tjänsten och GitHub Enterprise Server och använder lokalt installerade agenter för att skapa kod, får du en försämrad upplevelse:

  • Du måste ange namnet på lagringsplatsen manuellt när pipelinen skapas
  • Du kan inte använda CI- eller PR-utlösare eftersom Azure Pipelines inte kan registrera en webhook i GitHub Enterprise Server
  • Du kan inte använda schemalagda utlösare med alternativet att endast skapa när det finns ändringar
  • Du kan inte visa information om den senaste incheckningen i användargränssnittet

Om du vill konfigurera YAML-pipelines eller om du vill förbättra upplevelsen med klassiska pipelines är det viktigt att du aktiverar kommunikation från Azure Pipelines till GitHub Enterprise Server.

Om du vill tillåta trafik från Azure DevOps att nå din GitHub Enterprise Server lägger du till DE IP-adresser eller tjänsttaggar som anges i Inkommande anslutningar till brandväggens tillåtna lista. Om du använder ExpressRoute måste du även inkludera ExpressRoute IP-intervall i brandväggens tillåtna lista.

Begränsningar

  • För bästa prestanda rekommenderar vi högst 50 pipelines på en enda lagringsplats. För godtagbara prestanda rekommenderar vi högst 100 pipelines på en enda lagringsplats. Tiden som krävs för att bearbeta en push-överföring till en lagringsplats ökar med antalet pipelines på lagringsplatsen. När det finns push-överföring till en lagringsplats måste Azure Pipelines läsa in alla YAML-pipelines på den lagringsplatsen för att ta reda på om någon av dem behöver köras och inläsning av varje pipeline medför prestandastraff. Förutom prestandaproblem kan för många pipelines på en enda lagringsplats leda till begränsning på GitHubs sida, eftersom Azure Pipelines kan göra för många begäranden på kort tid.

  • Användningen av utökar och inkluderar mallar i en pipeline påverkar den hastighet med vilken Azure Pipelines gör GitHub API-begäranden och kan leda till begränsning på GitHubs sida. Innan du kör en pipeline måste Azure Pipelines generera den fullständiga YAML-koden, så den måste hämta alla mallfiler.

  • Azure Pipelines läser in högst 2 000 grenar från en lagringsplats till listrutor i Azure DevOps-portalen, till exempel i fönstret Välj en gren för standardgrenen för manuella och schemalagda versioner , eller när du väljer en gren när du kör en pipeline manuellt.

    Om du inte ser önskad gren i listan skriver du önskat grennamn manuellt i fältet Standardgren för manuella och schemalagda versioner .

    Om du klickar på ellipsen och öppnar dialogrutan Välj en gren och stänger den utan att välja en giltig gren från listrutan kan du se ett meddelande om att Vissa inställningar behöver uppmärksammas och att den här inställningen är obligatorisk under Standardgren för manuella och schemalagda versioner. Om du vill kringgå det här meddelandet öppnar du pipelinen igen och anger namnet direkt i fältet Standardgren för manuella och schemalagda versioner .

Vanliga frågor

Problem som rör GitHub Enterprise-integrering finns i följande kategorier:

  • Utlösare som misslyckas: Min pipeline utlöses inte när jag skickar en uppdatering till lagringsplatsen.
  • Misslyckad utcheckning: Min pipeline utlöses, men den misslyckas i utcheckningssteget.
  • Fel version: Min pipeline körs, men den använder en oväntad version av källan/YAML.

Felutlösare

Jag har precis skapat en ny YAML-pipeline med CI/PR-utlösare, men pipelinen utlöses inte.

Följ vart och ett av dessa steg för att felsöka dina felutlösare:

  • Åsidosättas dina YAML CI- eller PR-utlösare av pipelineinställningar i användargränssnittet? När du redigerar din pipeline väljer du ... och sedan Utlösare.

    Användargränssnitt för pipelineinställningar.

    Kontrollera inställningen Åsidosätt YAML-utlösaren härifrån för de typer av utlösare (kontinuerlig integrering eller validering av pull-begäran) som är tillgängliga för lagringsplatsen.

    Åsidosätt YAML-utlösare härifrån.

  • Webhooks används för att kommunicera uppdateringar från GitHub Enterprise till Azure Pipelines. I GitHub Enterprise navigerar du till inställningarna för lagringsplatsen och sedan till Webhooks. Kontrollera att webhooks finns. Vanligtvis bör du se två webhooks – push, pull_request. Om du inte gör det måste du återskapa tjänstanslutningen och uppdatera pipelinen för att använda den nya tjänstanslutningen.

  • Välj var och en av webhooks i GitHub Enterprise och kontrollera att nyttolasten som motsvarar användarens incheckning finns och har skickats till Azure DevOps. Du kan se ett fel här om händelsen inte kunde kommuniceras med Azure DevOps.

  • När Azure Pipelines tar emot ett meddelande från GitHub försöker de kontakta GitHub och hämta mer information om lagringsplatsen och YAML-filen. Om GitHub Enterprise Server ligger bakom en brandvägg kanske den här trafiken inte når servern. Se Azure DevOps IP-adresser och kontrollera att du har beviljat undantag till alla nödvändiga IP-adresser. Dessa IP-adresser kan ha ändrats eftersom du ursprungligen har konfigurerat undantagsreglerna.

  • Har pipelinen pausats eller inaktiverats? Öppna redigeraren för pipelinen och välj sedan Inställningar att kontrollera. Om pipelinen är pausad eller inaktiverad fungerar inte utlösare.

  • Har du uppdaterat YAML-filen i rätt gren? Om du skickar en uppdatering till en gren styr YAML-filen i samma gren CI-beteendet. Om du skickar en uppdatering till en källgren styr YAML-filen som uppstår när källgrenen slås samman med målgrenen PR-beteendet. Kontrollera att YAML-filen i rätt gren har nödvändig CI- eller PR-konfiguration.

  • Har du konfigurerat utlösaren korrekt? När du definierar en YAML-utlösare kan du ange både inkludera och exkludera satser för grenar, taggar och sökvägar. Se till att inkluderingssatsen matchar informationen om incheckningen och att exkluderingssatsen inte utesluter dem. Kontrollera syntaxen för utlösarna och kontrollera att den är korrekt.

  • Har du använt variabler för att definiera utlösaren eller sökvägarna? Det stöds inte.

  • Använde du mallar för YAML-filen? I så fall kontrollerar du att utlösarna har definierats i yaml-huvudfilen. Utlösare som definieras i mallfiler stöds inte.

  • Har du exkluderat de grenar eller sökvägar som du har push-överfört ändringarna till? Testa genom att push-överföra en ändring till en inkluderad sökväg i en inkluderad gren. Observera att sökvägarna i utlösare är skiftlägeskänsliga. Kontrollera att du använder samma skiftläge som för riktiga mappar när du anger sökvägarna i utlösare.

  • Har du precis push-överfört en ny gren? I så fall kanske den nya grenen inte startar en ny körning. Se avsnittet "Beteende för utlösare när nya grenar skapas".

Mina CI- eller PR-utlösare har fungerat bra. Men de slutade fungera nu.

Gå först igenom felsökningsstegen i föregående fråga och följ sedan följande ytterligare steg:

  • Har du sammanslagningskonflikter i din PR? För en PR som inte utlöste en pipeline öppnar du den och kontrollerar om den har en sammanslagningskonflikt. Lös sammanslagningskonflikten.

  • Har du en fördröjning i bearbetningen av push- eller PR-händelser? Du kan vanligtvis kontrollera en fördröjning genom att se om problemet är specifikt för en enda pipeline eller är gemensamt för alla pipelines eller lagringsplatser i projektet. Om en push- eller PR-uppdatering till någon av lagringsplatserna uppvisar det här symptomet kan det uppstå fördröjningar i bearbetningen av uppdateringshändelserna. Här följer några orsaker till varför en fördröjning kan inträffa:

    • Vi upplever ett avbrott i tjänsten på vår statussida. Om statussidan visar ett problem måste vårt team redan ha börjat arbeta med det. Kontrollera sidan ofta för att få uppdateringar om problemet.
    • Lagringsplatsen innehåller för många YAML-pipelines. För bästa prestanda rekommenderar vi högst 50 pipelines på en enda lagringsplats. För godtagbara prestanda rekommenderar vi högst 100 pipelines på en enda lagringsplats. Ju fler pipelines det finns, desto långsammare bearbetning av en push-överföring till lagringsplatsen. När det finns push-överföring till en lagringsplats måste Azure Pipelines läsa in alla YAML-pipelines på den lagringsplatsen för att ta reda på om någon av dem behöver köras, och varje ny pipeline medför prestandastraff.
    • Din GitHub Enterprise Server-instans kan vara underetablerade, vilket gör bearbetningen av begäranden från Azure Pipelines långsammare. Läs mer om maskinvaruöverväganden för GitHub Enterprise Server.

Misslyckad utcheckning

Använder du Microsoft-värdbaserade agenter? I så fall kanske dessa agenter inte kan nå din GitHub Enterprise Server. Mer information finns i Kan inte nås från Microsoft-värdbaserade agenter .

Fel version

En fel version av YAML-filen används i pipelinen. Varför är den det?

  • För CI-utlösare utvärderas YAML-filen som finns i grenen som du pushar för att se om en CI-version ska köras.
  • För PR-utlösare utvärderas YAML-filen som härrör från sammanslagning av käll- och målgrenarna för PR för att se om en PR-version ska köras.