GitHub Enterprise Server-opslagplaatsen bouwen

Artikel
01/31/2024

Azure DevOps Services

U kunt uw on-premises GitHub Enterprise Server integreren met Azure Pipelines. Uw on-premises server wordt mogelijk blootgesteld aan internet of niet.

Als uw GitHub Enterprise Server bereikbaar is vanaf de servers waarop de Azure Pipelines-service wordt uitgevoerd, doet u het volgende:

u kunt klassieke build- en YAML-pijplijnen instellen
u KUNT CI-, PR- en geplande triggers configureren

Als uw GitHub Enterprise Server niet bereikbaar is vanaf de servers waarop de Azure Pipelines-service wordt uitgevoerd, doet u het volgende:

u kunt alleen klassieke build-pijplijnen instellen
u kunt alleen handmatige of geplande builds starten
u kunt GEEN YAML-pijplijnen instellen
u kunt geen CI- of PULL-triggers configureren voor uw klassieke build-pijplijnen

Als uw on-premises server bereikbaar is vanaf door Microsoft gehoste agents, kunt u deze gebruiken om uw pijplijnen uit te voeren. Anders moet u zelf-hostende agents instellen die toegang hebben tot uw on-premises server en de code ophalen.

Bereikbaar vanuit Azure Pipelines

Het eerste wat u moet controleren, is of uw GitHub Enterprise Server bereikbaar is vanuit de Azure Pipelines-service.

Navigeer in uw Azure DevOps-gebruikersinterface naar uw projectinstellingen en selecteer serviceverbindingen onder Pijplijnen.
Selecteer Nieuwe serviceverbinding en kies GitHub Enterprise Server als verbindingstype.
Voer de vereiste gegevens in om een verbinding met uw GitHub Enterprise Server te maken.
Selecteer Verifiëren in het deelvenster Serviceverbinding.

Als de verificatie is geslaagd, kunnen de servers waarop de Azure Pipelines-service wordt uitgevoerd uw on-premises GitHub Enterprise Server bereiken. U kunt doorgaan en de verbinding instellen. Vervolgens kunt u deze serviceverbinding gebruiken bij het maken van een klassieke build- of YAML-pijplijn. U kunt ook CI- en PR-triggers configureren voor de pijplijn. Een meerderheid van de functies in Azure Pipelines die met GitHub werken, werken ook met GitHub Enterprise Server. Raadpleeg de documentatie voor GitHub om deze functies te begrijpen. Hier volgen enkele verschillen:

De integratie tussen GitHub en Azure Pipelines wordt eenvoudiger gemaakt via een Azure Pipelines-app in GitHub Marketplace. Met deze app kunt u een integratie instellen zonder dat u hoeft te vertrouwen op het OAuth-token van een bepaalde gebruiker. We hebben geen vergelijkbare app die werkt met GitHub Enterprise Server. U moet dus een PAT, gebruikersnaam en wachtwoord of OAuth gebruiken om de verbinding tussen Azure Pipelines en GitHub Enterprise-server in te stellen.
Azure Pipelines ondersteunt een aantal GitHub-beveiligingsfuncties om bijdragen van externe forks te valideren. Geheimen die zijn opgeslagen in een pijplijn, worden bijvoorbeeld niet beschikbaar gesteld aan een actieve taak. Deze beveiligingen zijn niet beschikbaar wanneer u werkt met de GitHub Enterprise-server.
Opmerkingentriggers zijn niet beschikbaar voor de GitHub Enterprise-server. U kunt geen opmerkingen gebruiken in een pull-aanvraag voor een GitHub Enterprise-serveropslagplaats om een pijplijn te activeren.
GitHub-controles zijn niet beschikbaar op de GitHub Enterprise-server. Alle statusupdates worden uitgevoerd via basisstatussen.

Niet bereikbaar vanuit Azure Pipelines

Wanneer de verificatie van een GitHub Enterprise Server-verbinding zoals uitgelegd in de bovenstaande sectie mislukt, kan Azure Pipelines niet communiceren met uw server. Dit wordt waarschijnlijk veroorzaakt door de configuratie van uw bedrijfsnetwerk. Een firewall in uw netwerk kan bijvoorbeeld voorkomen dat extern verkeer uw servers bereikt. In dit geval hebt u twee opties:

Werk samen met uw IT-afdeling om een netwerkpad te openen tussen Azure Pipelines en GitHub Enterprise Server. U kunt bijvoorbeeld uitzonderingen toevoegen aan uw firewallregels om verkeer van Azure Pipelines door te laten stromen. Zie de sectie over Ip-adressen van Azure DevOps om te zien welke IP-adressen u moet toestaan. Bovendien moet u een openbare DNS-vermelding hebben voor de GitHub Enterprise Server, zodat Azure Pipelines de FQDN van uw server kan omgezet in een IP-adres. Met al deze wijzigingen probeert u een GitHub Enterprise Server-verbinding te maken en te verifiëren in Azure Pipelines.
In plaats van een GitHub Enterprise Server-verbinding te gebruiken, kunt u een andere Git-verbinding gebruiken. Zorg ervoor dat u de optie voor het openen van deze Git-server vanuit Azure Pipelines uitschakelt. Met dit verbindingstype kunt u alleen een klassieke build-pijplijn configureren. CI- en PULL-triggers werken niet in deze configuratie. U kunt alleen handmatige of geplande pijplijnuitvoeringen starten.

Bereikbaar vanaf door Microsoft gehoste agents

Een andere beslissing die u mogelijk moet nemen, is of u door Microsoft gehoste agents of zelf-hostende agents moet gebruiken om uw pijplijnen uit te voeren. Dit komt vaak neer op of door Microsoft gehoste agents uw server kunnen bereiken. Als u wilt controleren of dit mogelijk is, maakt u een eenvoudige pijplijn voor het gebruik van door Microsoft gehoste agents en moet u een stap toevoegen om de broncode van uw server te bekijken. Als dit wordt doorgegeven, kunt u doorgaan met het gebruik van door Microsoft gehoste agents.

Niet bereikbaar vanaf door Microsoft gehoste agents

Als de eenvoudige testpijplijn die in de bovenstaande sectie wordt genoemd, mislukt met de fout 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, is de GitHub Enterprise Server niet bereikbaar vanaf door Microsoft gehoste agents. Dit wordt waarschijnlijk veroorzaakt door een firewall die verkeer van deze servers blokkeert. In dit geval hebt u twee opties:

Werk samen met uw IT-afdeling om een netwerkpad te openen tussen door Microsoft gehoste agents en GitHub Enterprise Server. Zie de sectie over netwerken in door Microsoft gehoste agents.
Schakel over naar het gebruik van zelf-hostende agents of schaalsetagents. Deze agents kunnen worden ingesteld binnen uw netwerk en hebben daarom toegang tot de GitHub Enterprise Server. Voor deze agents zijn alleen uitgaande verbindingen met Azure Pipelines vereist. U hoeft geen firewall te openen voor binnenkomende verbindingen. Zorg ervoor dat de naam van de server die u hebt opgegeven bij het maken van de GitHub Enterprise Server-verbinding kan worden omgezet vanuit de zelf-hostende agents.

IP-adressen van Azure DevOps

Azure Pipelines verzendt aanvragen naar GitHub Enterprise Server naar:

Query's uitvoeren op een lijst met opslagplaatsen tijdens het maken van pijplijnen (klassieke en YAML-pijplijnen)
Zoek naar bestaande YAML-bestanden tijdens het maken van pijplijnen (YAML-pijplijnen)
YAML-bestanden (YAML-pijplijnen) inchecken
Een webhook registreren tijdens het maken van pijplijnen (klassieke en YAML-pijplijnen)
Een editor presenteren voor YAML-bestanden (YAML-pijplijnen)
Sjablonen oplossen en YAML-bestanden uitvouwen vóór uitvoering (YAML-pijplijnen)
Controleer of er wijzigingen zijn sinds de laatste geplande uitvoering (klassieke en YAML-pijplijnen)
Details ophalen over de meest recente doorvoer en weergeven die in de gebruikersinterface (klassieke en YAML-pijplijnen)

U kunt zien dat YAML-pijplijnen fundamenteel communicatie vereisen tussen Azure Pipelines en GitHub Enterprise Server. Daarom is het niet mogelijk om een YAML-pijplijn in te stellen als de GitHub Enterprise Server niet zichtbaar is voor Azure Pipelines.

Wanneer u een andere Git-verbinding gebruikt om een klassieke pijplijn in te stellen, schakelt u de communicatie tussen de Azure Pipelines-service en GitHub Enterprise Server uit en gebruikt u zelf-hostende agents om code te bouwen, krijgt u een verminderde ervaring:

U moet de naam van de opslagplaats handmatig typen tijdens het maken van de pijplijn
U kunt GEEN CI- of PR-triggers gebruiken omdat Azure Pipelines geen webhook kan registreren in GitHub Enterprise Server
U kunt geplande triggers niet gebruiken met de optie om alleen te bouwen wanneer er wijzigingen zijn
U kunt geen informatie weergeven over de meest recente doorvoer in de gebruikersinterface

Als u YAML-pijplijnen wilt instellen of als u de ervaring met klassieke pijplijnen wilt verbeteren, is het belangrijk dat u communicatie van Azure Pipelines naar GitHub Enterprise Server inschakelt.

Als u wilt toestaan dat verkeer van Azure DevOps uw GitHub Enterprise Server bereikt, voegt u de IP-adressen of servicetags toe die zijn opgegeven in binnenkomende verbindingen met de acceptatielijst van uw firewall. Als u ExpressRoute gebruikt, moet u ook ExpressRoute-IP-bereiken opnemen in de acceptatielijst van uw firewall.

Beperkingen

Voor de beste prestaties raden we maximaal 50 pijplijnen in één opslagplaats aan. Voor acceptabele prestaties raden we maximaal 100 pijplijnen aan in één opslagplaats. De tijd die nodig is om een push naar een opslagplaats te verwerken, neemt toe met het aantal pijplijnen in die opslagplaats. Wanneer er naar een opslagplaats wordt gepusht, moeten azure Pipelines alle YAML-pijplijnen in die opslagplaats laden om erachter te komen of een van deze pijplijnen moet worden uitgevoerd en elke pijplijn wordt geladen, wordt een prestatiestraf opgelegd. Naast prestatieproblemen kan het hebben van te veel pijplijnen in één opslagplaats leiden tot beperking aan de zijde van GitHub, omdat Azure Pipelines in korte tijd te veel aanvragen kan indienen.
Het gebruik van uitbreidingen en het opnemen van sjablonen in een pijplijn heeft invloed op de snelheid waarmee Azure Pipelines GitHub API-aanvragen doet en kan leiden tot beperking aan de zijde van GitHub. Voordat u een pijplijn uitvoert, moet Azure Pipelines de volledige YAML-code genereren, zodat alle sjabloonbestanden moeten worden opgehaald.
Azure Pipelines laadt maximaal 2000 vertakkingen uit een opslagplaats in vervolgkeuzelijsten in de Azure DevOps-portal, bijvoorbeeld in het venster Een vertakking selecteren voor de standaardvertakking voor handmatige en geplande builds , of wanneer u een vertakking kiest wanneer u handmatig een pijplijn uitvoert.

Als u de gewenste vertakking niet in de lijst ziet, typt u de naam van de gewenste vertakking handmatig in de standaardbranch voor handmatige en geplande builds .

Als u op het beletselteken klikt en het dialoogvenster Een vertakking selecteren opent en deze sluit zonder een geldige vertakking te kiezen in de vervolgkeuzelijst, ziet u mogelijk een bericht dat aandacht nodig heeft voor sommige instellingen. De instelling is vereist onder Standaardvertakking voor handmatige en geplande builds. U kunt dit bericht omzeilen door de pijplijn opnieuw te openen en de naam rechtstreeks in de standaardbranch in te voeren voor het veld Handmatige en geplande builds .

Veelgestelde vragen

Problemen met betrekking tot GitHub Enterprise-integratie vallen in de volgende categorieën:

Mislukte triggers: Mijn pijplijn wordt niet geactiveerd wanneer ik een update naar de opslagplaats push.
Uitchecken mislukt: Mijn pijplijn wordt geactiveerd, maar mislukt in de stap voor uitchecken.
Verkeerde versie: Mijn pijplijn wordt uitgevoerd, maar er wordt een onverwachte versie van de bron/YAML gebruikt.

Mislukte triggers

Ik heb zojuist een nieuwe YAML-pijplijn gemaakt met CI/PR-triggers, maar de pijplijn wordt niet geactiveerd.

Volg deze stappen om problemen met uw mislukte triggers op te lossen:

Worden uw YAML CI- of PULL-triggers overschreven door pijplijninstellingen in de gebruikersinterface? Kies tijdens het bewerken van uw pijplijn ... en vervolgens Triggers.

Controleer de YAML-trigger van hieruit negeren voor de typen triggers (continue integratie of validatie van pull-aanvragen) die beschikbaar zijn voor uw opslagplaats.

Webhooks worden gebruikt om updates van GitHub Enterprise te communiceren met Azure Pipelines. Navigeer in GitHub Enterprise naar de instellingen voor uw opslagplaats en ga vervolgens naar Webhooks. Controleer of de webhooks bestaan. Meestal ziet u twee webhooks: pushen, pull_request. Als u dat niet doet, moet u de serviceverbinding opnieuw maken en de pijplijn bijwerken om de nieuwe serviceverbinding te gebruiken.
Selecteer elk van de webhooks in GitHub Enterprise en controleer of de nettolading die overeenkomt met de doorvoer van de gebruiker bestaat en is verzonden naar Azure DevOps. Mogelijk ziet u hier een fout als de gebeurtenis niet kan worden gecommuniceerd met Azure DevOps.
Wanneer Azure Pipelines een melding van GitHub ontvangt, probeert deze contact op te nemen met GitHub en meer informatie over de opslagplaats en het YAML-bestand op te halen. Als de GitHub Enterprise Server zich achter een firewall bevindt, bereikt dit verkeer mogelijk uw server niet. Zie Ip-adressen van Azure DevOps en controleer of u uitzonderingen hebt verleend op alle vereiste IP-adressen. Deze IP-adressen zijn mogelijk gewijzigd sinds u oorspronkelijk de uitzonderingsregels hebt ingesteld.

Is uw pijplijn onderbroken of uitgeschakeld? Open de editor voor de pijplijn en selecteer Vervolgens Instellingen om te controleren. Als uw pijplijn is onderbroken of uitgeschakeld, werken triggers niet.
Hebt u het YAML-bestand in de juiste vertakking bijgewerkt? Als u een update naar een vertakking pusht, bepaalt het YAML-bestand in diezelfde vertakking het CI-gedrag. Als u een update naar een bronbranch pusht, bepaalt het YAML-bestand dat het gevolg is van het samenvoegen van de bronbranch met de doelbranch het gedrag van de pull-aanvraag. Zorg ervoor dat het YAML-bestand in de juiste vertakking de benodigde CI- of PR-configuratie heeft.
Hebt u de trigger correct geconfigureerd? Wanneer u een YAML-trigger definieert, kunt u zowel component opnemen als uitsluiten voor vertakkingen, tags en paden opgeven. Zorg ervoor dat de include-component overeenkomt met de details van uw doorvoer en dat de exclude-component deze niet uitsluit. Controleer de syntaxis voor de triggers en controleer of deze juist is.
Hebt u variabelen gebruikt bij het definiëren van de trigger of de paden? Dat wordt niet ondersteund.
Hebt u sjablonen gebruikt voor uw YAML-bestand? Als dit het geval is, moet u ervoor zorgen dat uw triggers zijn gedefinieerd in het hoofd-YAML-bestand. Triggers die in sjabloonbestanden zijn gedefinieerd, worden niet ondersteund.
Hebt u de vertakkingen of paden waarnaar u uw wijzigingen hebt gepusht uitgesloten? Test door een wijziging naar een opgenomen pad in een opgenomen vertakking te pushen. Houd er rekening mee dat paden in triggers hoofdlettergevoelig zijn. Zorg ervoor dat u dezelfde case gebruikt als die van echte mappen bij het opgeven van de paden in triggers.
Heb je net een nieuwe vertakking gepusht? Zo ja, dan start de nieuwe vertakking mogelijk geen nieuwe uitvoering. Zie de sectie 'Gedrag van triggers wanneer nieuwe vertakkingen worden gemaakt'.

Mijn CI- of PR-triggers werken prima. Maar ze werkten nu niet meer.

Voer eerst de stappen voor probleemoplossing in de vorige vraag uit en volg deze aanvullende stappen:

Hebt u samenvoegingsconflicten in uw pull-aanvraag? Voor een pull-aanvraag die geen pijplijn heeft geactiveerd, opent u deze en controleert u of er een samenvoegingsconflict is opgetreden. Los het samenvoegingsconflict op.
Ondervindt u een vertraging bij het verwerken van push- of pull-gebeurtenissen? U kunt meestal een vertraging controleren door te zien of het probleem specifiek is voor één pijplijn of gebruikelijk is voor alle pijplijnen of opslagplaatsen in uw project. Als een push- of PULL-update naar een van de opslagplaatsen dit symptoom vertoont, kunnen er vertragingen optreden bij het verwerken van de updategebeurtenissen. Hier volgen enkele redenen waarom een vertraging kan optreden:
- Er is een servicestoring op onze statuspagina. Als op de statuspagina een probleem wordt weergegeven, moet het team al aan het werk zijn. Controleer regelmatig de pagina op updates over het probleem.
- Uw opslagplaats bevat te veel YAML-pijplijnen. Voor de beste prestaties raden we maximaal 50 pijplijnen in één opslagplaats aan. Voor acceptabele prestaties raden we maximaal 100 pijplijnen aan in één opslagplaats. Hoe meer pijplijnen er zijn, hoe langzamer de verwerking van een push naar die opslagplaats. Wanneer er naar een opslagplaats wordt gepusht, moeten azure Pipelines alle YAML-pijplijnen in die opslagplaats laden om erachter te komen of een van deze pijplijnen moet worden uitgevoerd en elke nieuwe pijplijn een prestatiestraf krijgt.
- Uw GitHub Enterprise Server-exemplaar is mogelijk niet beschikbaar, waardoor de verwerking van aanvragen van Azure Pipelines wordt vertraagd. Lees meer over hardwareoverwegingen voor GitHub Enterprise Server.

Uitchecken mislukt

Gebruikt u door Microsoft gehoste agents? Zo ja, dan kunnen deze agents mogelijk uw GitHub Enterprise Server niet bereiken. Zie Niet bereikbaar vanaf door Microsoft gehoste agents voor meer informatie.

Verkeerde versie

Er wordt een verkeerde versie van het YAML-bestand gebruikt in de pijplijn. Waarom is dat?

Voor CI-triggers wordt het YAML-bestand dat zich in de vertakking bevindt die u pusht geëvalueerd om te zien of een CI-build moet worden uitgevoerd.
Voor PULL-triggers wordt het YAML-bestand dat voortvloeit uit het samenvoegen van de bron- en doelbranches van de pull-aanvraag geëvalueerd om te zien of een PULL-build moet worden uitgevoerd.

Delen via