Erstellen von GitHub Enterprise Server-Repositorys

Azure DevOps Services

Sie können Ihren lokalen GitHub Enterprise Server mit Azure Pipelines integrieren. Ihr lokaler Server ist möglicherweise für das Internet verfügbar oder nicht verfügbar.

Wenn Ihr GitHub Enterprise Server von den Servern erreichbar ist, auf denen der Azure Pipelines-Dienst ausgeführt wird, dann:

• können Sie klassische Build- und YAML-Pipelines einrichten
• können Sie CI-, PR- und Plantrigger konfigurieren

Wenn Ihr GitHub Enterprise Server von den Servern nicht erreichbar ist, auf denen der Azure Pipelines-Dienst ausgeführt wird, dann:

• können Sie nur klassische Buildpipelines einrichten
• können Sie nur manuelle oder geplante Buildprozesse starten
• können Sie keine YAML-Pipelines einrichten
• können Sie keine CI- oder PR-Trigger für Ihre klassischen Buildpipelines konfigurieren

Wenn Ihr lokaler Server über von Microsoft gehostete Agents erreichbar ist, können Sie diese zum Ausführen Ihrer Pipelines verwenden. Andernfalls müssen Sie selbstgehostete Agents einrichten, die auf Ihren lokalen Server zugreifen und den Code abrufen können.

Erreichbar über Azure Pipelines

Zunächst müssen Sie überprüfen, ob Ihr GitHub Enterprise Server über den Azure Pipelines-Dienst erreichbar ist.

1. Navigieren Sie auf der Azure DevOps-Benutzeroberfläche zu Ihren Projekteinstellungen, und wählen Sie unter Pipelines die Option Dienstverbindungen aus.
2. Wählen Sie Neue Dienstverbindung und dann GitHub Enterprise Server als Verbindungstyp aus.
3. Geben Sie die erforderlichen Informationen ein, um eine Verbindung mit Ihrem GitHub Enterprise Server herzustellen.
4. Wählen Sie im Dienstverbindungsbereich die Option Überprüfen aus.

Wenn die Überprüfung erfolgreich ist, können die Server, auf denen der Azure Pipelines-Dienst ausgeführt wird, Ihren lokalen GitHub Enterprise Server erreichen. Sie können fortfahren und die Verbindung einrichten. Anschließend können Sie diese Dienstverbindung verwenden, wenn Sie eine klassische Build- oder YAML-Pipeline erstellen. Sie können auch CI- und PR-Trigger für die Pipeline konfigurieren. Die meisten Features in Azure Pipelines, die mit GitHub funktionieren, funktionieren auch mit GitHub Enterprise Server. Lesen Sie die Dokumentation für GitHub, um sich mit diesen Features vertraut zu machen. Hier werden einige der Unterschiede aufgelistet:

• Die Integration zwischen GitHub und Azure Pipelines wird durch eine Azure Pipelines-App im GitHub Marketplace vereinfacht. Mit dieser App können Sie eine Integration einrichten, ohne sich auf das OAuth-Token eines bestimmten Benutzers verlassen zu müssen. Wir verfügen nicht über eine ähnliche App, die mit GitHub Enterprise Server funktioniert. Sie müssen also ein PAT, einen Benutzernamen und ein Kennwort oder OAuth verwenden, um die Verbindung zwischen Azure Pipelines und GitHub Enterprise Server einzurichten.
• Azure Pipelines unterstützt eine Reihe von GitHub-Sicherheitsfeatures, um Beiträge von externen Forks zu überprüfen. Beispielsweise werden in einer Pipeline gespeicherte Geheimnisse für einen ausgeführten Auftrag nicht zur Verfügung gestellt. Diese Schutzmaßnahmen sind bei der Arbeit mit GitHub Enterprise Server nicht verfügbar.
• Kommentartrigger sind für GitHub Enterprise Server nicht verfügbar. Sie können Kommentare in einem Pull Request eines GitHub Enterprise Server-Repositorys nicht verwenden, um eine Pipeline auszulösen.
• GitHub-Überprüfungen sind in GitHub Enterprise Server nicht verfügbar. Alle Statusaktualisierungen durchlaufen grundlegende Statuswerte.

Nicht erreichbar von Azure Pipelines

Wenn die Überprüfung einer GitHub Enterprise Server-Verbindung, wie im obigen Abschnitt erläutert, fehlschlägt, ist keine Kommunikation zwischen Azure Pipelines und Ihrem Server möglich. Dies wird wahrscheinlich durch die Einrichtung Ihres Unternehmensnetzwerks verursacht. Beispielsweise kann eine Firewall in Ihrem Netzwerk verhindern, dass externer Datenverkehr Ihre Server erreicht. In diesem Fall haben Sie zwei Möglichkeiten:

• Arbeiten Sie mit Ihrer IT-Abteilung zusammen, um einen Netzwerkpfad zwischen Azure Pipelines und GitHub Enterprise Server zu öffnen. Beispielsweise können Sie Ihren Firewallregeln Ausnahmen hinzufügen, um den Datenverkehr von Azure Pipelines zuzulassen. Im Abschnitt zu IP-Adressen von Azure DevOps erfahren Sie, welche IP-Adressen Sie zulassen müssen. Darüber hinaus benötigen Sie einen öffentlichen DNS-Eintrag für den GitHub Enterprise Server, damit Azure Pipelines den FQDN Ihres Servers in eine IP-Adresse auflösen kann. Versuchen Sie mit all diesen Änderungen, eine GitHub Enterprise Server-Verbindung in Azure Pipelines zu erstellen und zu überprüfen.

• Statt einer GitHub Enterprise Server-Verbindung können Sie eine andere Git-Verbindung verwenden. Achten Sie darauf, die Option zu deaktivieren, mit der Sie Zugriff auf diesen Git-Server von Azure Pipelines aus versuchen. Mit diesem Verbindungstyp können Sie nur eine klassische Buildpipeline konfigurieren. CI- und PR-Trigger funktionieren in dieser Konfiguration nicht. Sie können nur manuelle oder geplante Pipelineausführungen starten.

Erreichbar über von Microsoft gehostete Agents

Eine weitere Entscheidung, die Sie möglicherweise treffen müssen, ist die Verwendung von von Microsoft gehosteten Agents oder selbstgehosteten Agents zum Ausführen Ihrer Pipelines. Dies ist häufig davon abhängig, ob von Microsoft gehostete Agents Ihren Server erreichen können. Um zu überprüfen, ob dies möglich ist, erstellen Sie eine einfache Pipeline, um von Microsoft gehostete Agents zu verwenden, und fügen Sie einen Schritt hinzu, um den Quellcode von Ihrem Server auszuchecken. Wenn dies erfolgreich ist, können Sie weiterhin von Microsoft gehostete Agents verwenden.

Nicht erreichbar über von Microsoft gehostete Agents

Wenn die im obigen Abschnitt erwähnte einfache Testpipeline mit dem Fehler 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 fehlschlägt, kann der GitHub Enterprise Server durch von Microsoft gehostete Agents nicht erreicht werden. Auch dies wird wahrscheinlich durch eine Firewall verursacht, die Datenverkehr von diesen Servern blockiert. In diesem Fall haben Sie zwei Möglichkeiten:

• Arbeiten Sie mit Ihrer IT-Abteilung zusammen, um einen Netzwerkpfad zwischen von Microsoft gehosteten Agents und GitHub Enterprise Server zu öffnen. Weitere Informationen finden Sie im Abschnitt zum Netzwerk in von Microsoft gehosteten Agents.

• Steigen Sie auf die Verwendung von selbstgehosteten Agents oder Skalierungsgruppen-Agents um. Diese Agents können in Ihrem Netzwerk eingerichtet werden und besitzen daher Zugriff auf den GitHub Enterprise Server. Diese Agents erfordern nur ausgehende Verbindungen mit Azure Pipelines. Es ist nicht erforderlich, eine Firewall für eingehende Verbindungen zu öffnen. Vergewissern Sie sich, dass der Name des Servers, den Sie beim Erstellen der GitHub Enterprise Server-Verbindung angegeben haben, von den selbstgehosteten Agents aufgelöst werden kann.

IP-Adressen von Azure DevOps

Von Azure Pipelines werden zu folgenden Zwecken Anforderungen an GitHub Enterprise Server gesendet:

• Abfragen einer Liste von Repositorys während der Pipelineerstellung (klassische und YAML-Pipelines)
• Suche nach vorhandenen YAML-Dateien während der Pipelineerstellung (YAML-Pipelines)
• Einchecken von YAML-Dateien (YAML-Pipelines)
• Registrieren eines Webhooks während der Pipelineerstellung (klassische und YAML-Pipelines)
• Präsentieren eines Editors für YAML-Dateien (YAML-Pipelines)
• Auflösen von Vorlagen und Erweitern von YAML-Dateien vor der Ausführung (YAML-Pipelines)
• Überprüfen, ob seit der letzten geplanten Ausführung Änderungen vorgenommen wurden (klassische und YAML-Pipelines).
• Abrufen von Details zum neuesten Commit und Anzeigen dieser in der Benutzeroberfläche (klassische und YAML-Pipelines)

Sie können feststellen, dass YAML-Pipelines grundsätzlich die Kommunikation zwischen Azure Pipelines und GitHub Enterprise Server erfordern. Daher ist es nicht möglich, eine YAML-Pipeline einzurichten, wenn der GitHub Enterprise Server für Azure Pipelines nicht sichtbar ist.

Wenn Sie andere Git-Verbindungen verwenden, um eine klassische Pipeline einzurichten, die Kommunikation zwischen dem Azure Pipelines-Dienst und dem GitHub Enterprise Server zu deaktivieren und selbstgehostete Agents zum Erstellen von Code zu verwenden, erhalten Sie ein beeinträchtigtes Nutzungserlebnis:

• Sie müssen den Namen des Repositorys während der Pipelineerstellung manuell eingeben.
• Sie können keine CI- oder PR-Trigger verwenden, da von Azure Pipelines kein Webhook in GitHub Enterprise Server registriert werden kann.
• Sie können keine geplanten Trigger mit der Option verwenden, dass eine Erstellung nur erfolgt, wenn Änderungen vorhanden sind.
• Sie können keine Informationen zum neuesten Commit auf der Benutzeroberfläche anzeigen.

Wenn Sie YAML-Pipelines einrichten oder das Nutzungserlebnis mit klassischen Pipelines verbessern möchten, ist es wichtig, dass Sie die Kommunikation zwischen Azure Pipelines und GitHub Enterprise Server aktivieren.

Damit Datenverkehr von Azure DevOps Ihren GitHub Enterprise Server erreichen kann, fügen Sie der Positivliste Ihrer Firewall die IP-Adressen oder Diensttags hinzu, die in Eingehenden Verbindungen angegeben sind. Wenn Sie ExpressRoute verwenden, achten Sie darauf, dass Sie auch ExpressRoute-IP-Bereiche in die Positivliste Ihrer Firewall aufnehmen.

Begrenzungen

• Für eine optimale Leistung empfehlen wir maximal 50 Pipelines in einem einzelnen Repository. Für eine akzeptable Leistung empfehlen wir maximal 100 Pipelines in einem einzelnen Repository. Die Zeit, die zum Verarbeiten eines Pushvorgangs an ein Repository erforderlich ist, erhöht sich mit der Anzahl der Pipelines in diesem Repository. Bei jedem Push in ein Repository muss Azure Pipelines alle YAML-Pipelines in diesem Repository laden, um herauszufinden, ob eine dieser Pipelines ausgeführt werden muss, und jede geladene Pipeline verursacht eine Leistungseinbuße. Wenn sich in einem einzigen Repository zu viele Pipelines befinden, führt dies nicht nur zu Leistungsproblemen sondern auch zu Drosselung auf GitHub-Seite, da Azure-Pipelines möglicherweise zu viele Anforderungen in kurzer Zeit ausführen.

• Die Verwendung von Extend- und Include-Vorlagen in einer Pipeline wirkt sich auf die Rate aus, mit der Azure Pipelines GitHub-API-Anforderungen ausführt, was zu Drosselung auf GitHub-Seite führen kann. Vor dem Ausführen einer Pipeline muss Azure Pipelines den vollständigen YAML-Code generieren. Hierzu müssen alle Vorlagendateien abgerufen werden.

• Azure Pipelines lädt maximal 2000 Verzweigungen aus einem Repository in Dropdownlisten im Azure DevOps-Portal, z. B. in dem Fenster Eine Verzweigung auswählen für die Standardbranch für manuelle und geplante Builds oder beim Auswählen einer Verzweigung, wenn eine Pipeline manuell ausgeführt wird.

  Wenn die gewünschte Verzweigung nicht in der Liste angezeigt wird, geben Sie den gewünschten Branch-Namen manuell in das Feld Standardbranch für manuelle und geplante Builds ein.

  Wenn Sie auf die Auslassungspunkte klicken und den Dialog Eine Verzweigung auswählen öffnen und schließen, ohne eine gültige Verzweigung aus der Dropdownliste auszuwählen, wird möglicherweise eine Meldung Einige Einstellungen benötigen Aufmerksamkeit angezeigt, und Diese Einstellung ist für manuelle und geplante Builds unter Standardbranch erforderlich. Um diese Meldung zu umgehen, öffnen Sie die Pipeline erneut, und geben Sie den Namen direkt in den Standardbranch für manuelle und geplante Builds ein.

Häufig gestellte Fragen

Probleme im Zusammenhang mit der Integration von GitHub Enterprise fallen in die folgenden Kategorien:

• Triggerfehler: Meine Pipeline wird nicht ausgelöst, wenn ich ein Update in das Repository pushe.
• Fehler beim Auschecken: Meine Pipeline wird ausgelöst, aber sie schlägt im Auscheckschritt fehl.
• Falsche Version: Meine Pipeline wird ausgeführt, aber es wird eine unerwartete Quell-/YAML-Version verwendet.

Triggerfehler

Ich habe eine neue YAML-Pipeline mit CI-/PR-Triggern erstellt, aber die Pipeline wird nicht ausgelöst.

Führen Sie die folgenden Schritte aus, um Fehler bei Triggern zu beheben:

• Werden Ihre YAML-CI- oder -PR-Trigger durch Pipelineeinstellungen in der Benutzeroberfläche überschrieben? Wählen Sie beim Bearbeiten Ihrer Pipeline ... und anschließend Trigger aus.

  

  Überprüfen Sie in der Einstellung YAML-Trigger von hier aus überschreiben, welche Triggertypen (Continuous Integration-Überprüfung oder Pull Request-Überprüfung) für Ihr Repository verfügbar sind.

  

• Webhooks werden verwendet, um Updates von GitHub Enterprise an Azure Pipelines zu übermitteln. Navigieren Sie in GitHub Enterprise zu den Einstellungen für Ihr Repository und dann zu Webhooks. Vergewissern Sie sich, dass die Webhooks vorhanden sind. Normalerweise sollten zwei Webhooks angezeigt werden: push, pull_request. Andernfalls müssen Sie die Dienstverbindung neu erstellen und die Pipeline so aktualisieren, dass die neue Dienstverbindung verwendet wird.

• Wählen Sie die beiden Webhooks in GitHub Enterprise aus, und überprüfen Sie, ob die Nutzdaten, die dem Commit des Benutzers entsprechen, vorhanden sind und erfolgreich an Azure DevOps gesendet wurden. Möglicherweise wird hier ein Fehler angezeigt, wenn das Ereignis nicht an Azure DevOps übermittelt werden konnte.

• Wenn Azure Pipelines eine Benachrichtigung von GitHub empfängt, wird versucht, GitHub zu kontaktieren und weitere Informationen zum Repository und zur YAML-Datei abzurufen. Wenn sich der GitHub Enterprise Server hinter einer Firewall befindet, gelangt dieser Datenverkehr möglicherweise nicht zu Ihrem Server. Lesen Sie IP-Adressen von Azure DevOps, und überprüfen Sie, ob Sie Ausnahmen für alle erforderlichen IP-Adressen vorgesehen haben. Diese IP-Adressen haben sich möglicherweise geändert, seit Sie die Ausnahmeregeln ursprünglich eingerichtet haben.

• Ist Ihre Pipeline angehalten oder deaktiviert? Öffnen Sie den Editor für die Pipeline, und wählen Sie Einstellungen aus, um dies zu überprüfen. Wenn Ihre Pipeline angehalten oder deaktiviert ist, funktionieren Trigger nicht.

• Haben Sie die YAML-Datei im richtigen Branch aktualisiert? Wenn Sie eine Aktualisierung an einen Branch pushen, steuert die YAML-Datei in diesem Branch das CI-Verhalten. Wenn Sie eine Aktualisierung an einen Quellbranch pushen, steuert die YAML-Datei, die sich aus dem Mergen des Quellbranchs mit dem Zielbranch ergibt, das PR-Verhalten. Stellen Sie sicher, dass die YAML-Datei im richtigen Branch über die erforderliche CI- oder PR-Konfiguration verfügt.

• Haben Sie den Trigger richtig konfiguriert? Wenn Sie einen YAML-Trigger definieren, können Sie sowohl Einschluss- als auch Ausschlussklauseln für Branches, Tags und Pfade angeben. Vergewissern Sie sich, dass die Einschlussklausel mit den Details Ihres Commits übereinstimmt und dass die Ausschlussklausel diese nicht ausschließt. Überprüfen Sie die Syntax für die Trigger, und stellen Sie sicher, dass sie korrekt ist.

• Haben Sie bei der Definition des Triggers oder der Pfade Variablen verwendet? Dies wird nicht unterstützt.

• Haben Sie Vorlagen für Ihre YAML-Datei verwendet? Wenn ja, stellen Sie sicher, dass Ihre Trigger in der YAML-Hauptdatei definiert sind. In Vorlagendateien definierte Trigger werden nicht unterstützt.

• Haben Sie die Branches oder Pfade ausgeschlossen, an die Sie Ihre Änderungen gepusht haben? Testen Sie dies, indem Sie eine Änderung an einen eingeschlossenen Pfad in einem eingeschlossenen Branch pushen. Denken Sie daran, dass bei Pfaden in Triggern die Groß-/Kleinschreibung beachtet wird. Stellen Sie sicher, dass Sie beim Angeben der Pfade in Triggern dieselbe Groß-/Kleinschreibung verwenden wie bei den tatsächlichen Ordnern.

• Haben Sie gerade einen neuen Branch gepusht? Wenn ja, startet der neue Branch möglicherweise keine neue Ausführung. Weitere Informationen finden Sie im Abschnitt „Verhalten von Triggern beim Erstellen neuer Branches“.

Meine CI- oder PR-Trigger haben einwandfrei funktioniert. Aber jetzt funktionieren sie nicht mehr.

Führen Sie zunächst die Schritte zur Problembehandlung in der vorherigen Frage durch und dann die folgenden zusätzlichen Schritte aus:

• Liegen in Ihrem Pull Request Mergekonflikte vor? Öffnen Sie einen Pull Request, der keine Pipeline ausgelöst hat, und überprüfen Sie, ob ein Mergekonflikt vorliegt. Beheben Sie den Mergekonflikt.

• Kommt es zu einer Verzögerung bei der Verarbeitung von Push- oder Pull Request-Ereignissen? In der Regel können Sie eine Verzögerung überprüfen, indem Sie feststellen, ob das Problem nur bei einer einzelnen Pipeline oder bei allen Pipelines oder Repositorys in Ihrem Projekt auftritt. Wenn Sie dieses Symptom bei einer Push- oder Pull Request-Aktualisierung für eines der Repositorys feststellen, treten möglicherweise Verzögerungen bei der Verarbeitung der Aktualisierungsereignisse auf. Hier sind einige Gründe, warum eine Verzögerung auftreten kann:

  • Auf unserer Statusseite tritt ein Dienstausfall auf. Wenn auf der Seite „Status“ ein Problem angezeigt wird, hat unser Team bereits mit der Behebung begonnen. Überprüfen Sie die Seite regelmäßig auf Updates zum Problem.
  • Ihr Repository enthält zu viele YAML-Pipelines. Für eine optimale Leistung empfehlen wir maximal 50 Pipelines in einem einzelnen Repository. Für eine akzeptable Leistung empfehlen wir maximal 100 Pipelines in einem einzelnen Repository. Je mehr Pipelines vorhanden sind, desto langsamer ist die Verarbeitung eines Pushs an dieses Repository. Bei jedem Push in ein Repository muss Azure Pipelines alle YAML-Pipelines in diesem Repository laden, um herauszufinden, ob eine dieser Pipelines ausgeführt werden muss, und jede neue Pipeline verursacht eine Leistungseinbuße.
  • Ihre GitHub Enterprise Server-Instanz wird möglicherweise nicht bereitgestellt, und die Verarbeitung von Anforderungen von Azure Pipelines wird verlangsamt. Weitere Informationen zu Hardwareaspekten für GitHub Enterprise Server.

Fehler beim Check-Out

Verwenden Sie von Microsoft gehostete Agents? Wenn ja, können diese Agents Ihren GitHub Enterprise Server möglicherweise nicht erreichen. Weitere Informationen finden Sie unter Nicht erreichbar über von Microsoft gehostete Agents.

Falsche Version

In der Pipeline wird eine falsche Version der YAML-Datei verwendet. Warum?

• Bei CI-Triggern wird die YAML-Datei ausgewertet, die sich in dem von Ihnen gepushten Branch befindet, um festzustellen, ob ein CI-Build ausgeführt werden soll.
• Bei PR-Triggern wird die YAML-Datei, die sich aus dem Zusammenführen der Quell- und Zielbranches des Pull Requests ergibt, ausgewertet, um festzustellen, ob ein PR-Build ausgeführt werden soll.