Erstellen von GitHub-Repositorys

Azure DevOps Services

Azure Pipelines kann jeden Pull Request automatisch erstellen und überprüfen und einen Commit in Ihr GitHub-Repository ausführen. In diesem Artikel wird beschrieben, wie Sie die Integration zwischen GitHub und Azure Pipelines konfigurieren.

Wenn Sie mit der Integration von Pipelines in GitHub noch nicht vertraut sind, führen Sie die Schritte in Erstellen Ihrer ersten Pipeline aus. Kehren Sie dann zu diesem Artikel hier zurück, um zu erfahren, wie Sie die Integration zwischen GitHub und Azure Pipelines konfigurieren und anpassen.

Organisationen und Benutzer*innen

GitHub und Azure Pipelines sind voneinander zwei unabhängige Dienste, die sich integrieren lassen. Jeder dieser Dienste verfügt über eine eigene Organisations- und Benutzerverwaltung. In diesem Abschnitt finden Sie Empfehlungen dazu, wie Sie die Organisationen und Benutzer*innen von GitHub in Azure Pipelines replizieren.

Organisationen

Die Struktur von GitHub besteht aus Organisationen und Benutzerkonten, die Repositorys enthalten. Weitere Informationen finden Sie in der GitHub-Dokumentation.

Die Struktur von Azure DevOps besteht aus Organisationen, die Projekte enthalten. Weitere Informationen finden Sie unter Planen Ihrer Organisationsstruktur.

Azure DevOps kann Ihre GitHub-Struktur mit folgenden Elementen widerspiegeln:

• Eine DevOps-Organisation für Ihre Organisation oder Ihr Benutzerkonto in GitHub
• DevOps-Projekte für Ihre GitHub-Repositorys

So richten Sie eine identische Struktur in Azure DevOps ein:

1. Erstellen Sie eine DevOps-Organisation, die nach Ihrer Organisation oder Ihrem Benutzerkonto in GitHub benannt ist. Die URL sieht in etwa so aus: https://dev.azure.com/your-organization.
2. Erstellen Sie in der DevOps-Organisation Projekte, die Sie nach Ihren Repositorys benennen. Die URLs sehen in etwa so aus: https://dev.azure.com/your-organization/your-repository.
3. Erstellen Sie in der DevOps Projects-Instanz Pipelines – diese benennen Sie nach der GitHub-Organisation und den Repositorys, die sie erstellen. Beispiel: your-organization.your-repository. So ist klar, für welche Repositorys sie verwendet werden.

Nach diesem Muster erhalten Ihre GitHub-Repositorys und Azure DevOps Projects-Instanzen übereinstimmende URL-Pfade. Beispiel:

Dienst	URL
GitHub	https://github.com/python/cpython
Azure DevOps	https://dev.azure.com/python/cpython

Benutzer

Ihre GitHub-Benutzer*innen erhalten nicht automatisch Zugriff auf Azure Pipelines. Für Azure Pipelines sind GitHub-Identitäten unbekannt. Aus diesem Grund gibt es keine Möglichkeit, Azure Pipelines so zu konfigurieren, dass Benutzer*innen bei Buildfehlern oder Pull Request-Überprüfungsfehlern über ihre GitHub-Identität und entsprechende E-Mail-Adresse benachrichtigt werden. Sie müssen explizit neue Benutzer*innen in Azure Pipelines erstellen, um GitHub-Benutzer*innen zu replizieren. Nach dem Erstellen der neuen Benutzer*innen können Sie deren Berechtigungen in Azure DevOps so konfigurieren, dass sie ihre Berechtigungen in GitHub widerspiegeln. Sie können Benachrichtigungen in DevOps auch mithilfe von DevOps-Identitäten konfigurieren.

GitHub-Organisationsrollen

Die Mitgliedsrollen der GitHub-Organisation finden Sie unter https://github.com/orgs/your-organization/people (ersetzen Sie your-organization durch Ihre Organisation).

Berechtigungen für DevOps-Organisationsmitglieder finden Sie unter https://dev.azure.com/your-organization/_settings/security (ersetzen Sie your-organization durch Ihre Organisation).

Im Folgenden sehen Sie die Rollen in einer GitHub-Organisation und die entsprechenden Rollen in einer Azure DevOps-Organisation.

Rolle in der GitHub-Organisation	Entsprechung in der DevOps-Organisation
Besitzer	Mitglied von Project Collection Administrators
Abrechnungs-Manager	Mitglied von Project Collection Administrators
Member	Mitglied von Project Collection Valid Users Standardmäßig besitzt die Mitgliedergruppe keine Berechtigung zum Erstellen neuer Projekte. Um die Berechtigung zu ändern, legen Sie die Berechtigung Create new projects der Gruppe auf Allow fest, oder erstellen Sie eine neue Gruppe mit den erforderlichen Berechtigungen.

GitHub-Benutzerkontorollen

Ein GitHub-Benutzerkonto verfügt über eine Rolle: den Besitz des Kontos.

Berechtigungen für DevOps-Organisationsmitglieder finden Sie unter https://dev.azure.com/your-organization/_settings/security (ersetzen Sie your-organization durch Ihre Organisation).

Die GitHub-Benutzerkontorolle ist den DevOps-Organisationsberechtigungen wie folgt zugeordnet.

Rolle des GitHub-Benutzerkontos	Entsprechung in der DevOps-Organisation
Besitzer	Mitglied von Project Collection Administrators

GitHub-Repositoryberechtigungen

GitHub-Repositoryberechtigungen finden Sie unter https://github.com/your-organization/your-repository/settings/collaboration (ersetzen Sie your-organization und your-repository durch die zutreffenden Werte).

DevOps-Projektberechtigungen finden Sie unter https://dev.azure.com/your-organization/your-project/_settings/security (ersetzen Sie your-organization und your-project durch die zutreffenden Werte).

Im Folgenden sehen Sie die Entsprechungen zwischen Berechtigungen für GitHub-Repositorys und Azure DevOps Projects.

Berechtigung im GitHub-Repository	Entsprechung im DevOps-Projekt
Administrator	Mitglied von Project Administrators
Schreiben	Mitglied von Contributors
Lesen	Mitglied von Readers

Wenn Ihr GitHub-Repository Berechtigungen auf Teamebene gewährt, können Sie im Abschnitt Teams Ihrer Azure DevOps-Projekteinstellungen entsprechende Teams erstellen. Fügen Sie dann die Teams – genauso wie Benutzer*innen – zu den oben genannten Sicherheitsgruppen hinzu.

Pipelinespezifische Berechtigungen

Führen Sie die folgenden Schritte aus, um Benutzer*innen oder Teams Berechtigungen für bestimmte Pipelines in einem DevOps-Projekt zu gewähren:

1. Öffnen Sie die Seite „Pipelines“ des Projekts (z. B. https://dev.azure.com/your-organization/your-project/_build).
2. Wählen Sie die Pipeline aus, für die bestimmte Berechtigungen festgelegt werden sollen.
3. Wählen Sie im Kontextmenü mit den drei Auslassungspunkten (...) den Eintrag Sicherheit aus.
4. Wählen Sie Hinzufügen... aus, um bestimmte Benutzer*innen, bestimmte Teams oder Gruppen hinzuzufügen und deren Berechtigungen für die Pipeline anzupassen.

Zugriff auf GitHub-Repositorys

YAML

Zum Erstellen einer neuen Pipeline wählen Sie zunächst ein GitHub-Repository und dann eine YAML-Datei in diesem Repository aus. Das Repository, in dem sich die YAML-Datei befindet, wird als self-Repository bezeichnet. Standardmäßig ist dies das Repository, das Ihre Pipeline erstellt.

Sie können Ihre Pipeline später zum Auschecken eines oder mehrerer anderer Repositorys konfigurieren. Informationen dazu finden Sie unter Auschecken mehrerer Repositorys.

Klassisch

Sie erstellen eine neue Pipeline, indem Sie zunächst GitHub als Repositorytyp und dann eines der Repositorys auswählen, auf die Sie Zugriff haben.

Azure Pipelines muss Zugriff auf Ihre Repositorys erhalten, um die Builds auszulösen und während der Buildvorgänge ihren Code abzurufen.

Es gibt drei Authentifizierungsarten, um Azure Pipelines beim Erstellen einer Pipeline Zugriff auf Ihre GitHub-Repositorys zu gewähren.

Authentifizierungsart	Pipelineausführung verwendet	Funktioniert mit GitHub-Prüfungen
1. GitHub-App	Azure Pipelines-Identität	Ja
2. OAuth	Ihre persönliche GitHub-Identität	Nein
3. Persönliches Zugriffstoken (Personal Access Token, PAT)	Ihre persönliche GitHub-Identität	Nein

GitHub-App-Authentifizierung

Die Azure Pipelines-GitHub-App ist der empfohlene Authentifizierungstyp für Continuous Integration-Pipelines. Nachdem Sie die GitHub-App in Ihrem GitHub-Konto oder Ihrer GitHub-Organisation installiert haben, wird Ihre Pipeline ohne Ihre persönliche GitHub-Identität ausgeführt. Builds und GitHub-Statusaktualisierungen werden unter Verwendung der Azure Pipelines-Identität ausgeführt. Die App funktioniert mit GitHub-Prüfungen zum Anzeigen von Build-, Test- und Code Coverage-Ergebnissen in GitHub.

Um die GitHub-App zu verwenden, installieren Sie sie für einige oder alle Repositorys in Ihrer GitHub-Organisation oder Ihrem GitHub-Benutzerkonto. Die GitHub-App über die Homepage der App installiert und deinstalliert werden.

Nach der Installation wird die GitHub-App zur Standardmethode für die Authentifizierung von Azure Pipelines bei GitHub (anstelle von OAuth), wenn Pipelines für die Repositorys erstellt werden.

Wenn Sie die GitHub-App für alle Repositorys in einer GitHub-Organisation installieren, müssen Sie sich keine Sorgen machen, dass Azure Pipelines massenweise E-Mails sendet oder automatisch Pipelines in Ihrem Auftrag einrichtet. Als Alternative zum Installieren der App für alle Repositorys können Repositoryadministratoren sie auch jeweils einzeln für einzelne Repositorys installieren. Das ist zwar mehr Arbeit, hat aber weder Vor-noch Nachteile.

Erforderliche Berechtigungen in GitHub

Zum Installieren der Azure Pipelines-GitHub-App müssen Sie die Rolle „GitHub-Organisationsbesitzer“ oder „GitHub-Repositoryadministrator“ innehaben. Um eine Pipeline für ein GitHub-Repository mit Continuous Integration- und Pull Request-Triggern erstellen zu können, müssen zudem die erforderlichen GitHub-Berechtigungen für Sie konfiguriert sein. Andernfalls wird beim Erstellen der Pipeline das Repository nicht in der Repositoryliste angezeigt. Stellen Sie je nach Authentifizierungstyp und Besitz des Repositorys sicher, dass der entsprechende Zugriff konfiguriert ist.

• Wenn sich das Repository in Ihrem persönlichen GitHub-Konto befindet, installieren Sie die Azure Pipelines-GitHub-App in Ihrem persönlichen GitHub-Konto. Dann können Sie dieses Repository beim Erstellen der Pipeline in Azure Pipelines auflisten.

• Wenn sich das Repository im persönlichen GitHub-Konto einer anderen Person befindet, muss diese andere Person die Azure Pipelines-GitHub-App in ihrem persönlichen GitHub-Konto installieren. Sie müssen in den Einstellungen des Repositorys unter „Mitarbeiter“ als Mitarbeiter*in hinzugefügt werden. Akzeptieren Sie die Einladung über den Link, der Ihnen per E-Mail gesendet wird. Nachdem Sie dies getan haben, können Sie eine Pipeline für dieses Repository erstellen.

• Wenn sich das Repository in einer GitHub-Organisation in Ihrem Besitz befindet, installieren Sie die Azure Pipelines-GitHub-App in der GitHub-Organisation. Auch hier müssen Sie als Mitarbeiter*in hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter „Mitarbeiter und Teams“ hinzugefügt werden.

• Wenn sich das Repository in einer GitHub-Organisation im Besitz einer anderen Person befindet, muss jemand mit der Berechtigung als GitHub-Organisationsbesitzer oder -Repositoryadministrator die Azure Pipelines-GitHub-App in der Organisation installieren. Sie müssen als Mitarbeiter*in hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter „Mitarbeiter und Teams“ hinzugefügt werden. Akzeptieren Sie die Einladung über den Link, der Ihnen per E-Mail gesendet wird.

GitHub-App-Berechtigungen

Die GitHub-App fordert während der Installation die folgenden Berechtigungen an:

Berechtigung	Verwendung der Berechtigung in Azure Pipelines
Schreibzugriff auf Code	Nur nach einer bewussten Aktion Ihrerseits vereinfacht Azure Pipelines die Erstellung einer Pipeline, indem eine YAML-Datei in einen ausgewählten Branch Ihres GitHub-Repositorys committet wird.
Lesezugriff auf Metadaten	Azure Pipelines rufen GitHub-Metadaten ab, um das Repository, die Branches und die Issues in Zusammenhang mit einem Build in der Buildzusammenfassung anzuzeigen.
Lese- und Schreibzugriff auf Überprüfungen	Azure Pipelines liest und schreibt eigene Build-, Test- und Code Coverage-Ergebnisse, die in GitHub angezeigt werden sollen.
Lese- und Schreibzugriff auf Pull Requests	Nur nach einer bewussten Aktion Ihrerseits vereinfacht Azure Pipelines die Erstellung einer Pipeline, indem ein Pull Request für eine YAML-Datei erstellt wird, die in einen ausgewählten Branch Ihres GitHub-Repositorys committet wurde. Pipelines ruft Pull-Metadaten ab, die in Buildzusammenfassungen in Zusammenhang mit Pull-Anforderungen zugeordnet sind.

Problembehandlung bei der GitHub-App-Installation

GitHub zeigt möglicherweise einen Fehler wie diesen an:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Das bedeutet, dass die GitHub-App für Ihre Organisation wahrscheinlich bereits installiert ist. Wenn Sie eine Pipeline für ein Repository in der Organisation erstellen, wird die GitHub-App automatisch verwendet, um eine Verbindung mit GitHub herzustellen.

Erstellen von Pipelines in mehreren Azure DevOps-Organisationen und -Projekten

Nachdem die GitHub-App installiert wurde, können Pipelines für die Repositorys der Organisation in verschiedenen Azure DevOps-Organisationen und -Projekten erstellt werden. Wenn Sie jedoch Pipelines für ein einzelnes Repository in mehreren Azure DevOps-Organisationen erstellen, können nur die Pipelines der ersten Organisation automatisch durch GitHub-Commits oder -Pull Requests ausgelöst werden. Manuelle oder geplante Builds sind in sekundären Azure DevOps-Organisationen weiterhin möglich.

OAuth-Authentifizierung

OAuth ist der einfachste Authentifizierungstyp, mit dem Sie mit Repositorys in Ihrem persönlichen GitHub-Konto beginnen können. GitHub-Statusaktualisierungen werden im Namen Ihrer persönlichen GitHub-Identität ausgeführt. Damit die Pipelines weiterhin funktionieren, muss Ihr Repositoryzugriff aktiv bleiben. Einige GitHub-Features, z. B. Prüfungen, sind mit OAuth nicht verfügbar und erfordern die GitHub-App.

Um OAuth zu verwenden, wählen Sie beim Erstellen einer Pipeline unterhalb der Repositoryliste die Option Eine andere Verbindung auswählen aus. Wählen Sie dann Autorisieren aus, um sich bei GitHub anzumelden und mit OAuth zu autorisieren. Eine OAuth-Verbindung wird zur späteren Verwendung in Ihrem Azure DevOps-Projekt gespeichert und in der Pipeline verwendet, die gerade erstellt wird.

Erforderliche Berechtigungen in GitHub

Um eine Pipeline für ein GitHub-Repository mit Continuous Integration- und Pull Request-Triggern zu erstellen, müssen Sie die erforderlichen GitHub-Berechtigungen konfiguriert haben. Andernfalls wird beim Erstellen der Pipeline das Repository nicht in der Repositoryliste angezeigt. Stellen Sie je nach Authentifizierungstyp und Besitz des Repositorys sicher, dass der entsprechende Zugriff konfiguriert ist.

• Wenn sich das Repository in Ihrem persönlichen GitHub-Konto befindet, authentifizieren Sie sich mindestens einmal über OAuth mit Ihren persönlichen GitHub-Kontoanmeldeinformationen bei GitHub. Dies kann in den Azure DevOps-Projekteinstellungen unter „Pipelines“ > „Dienstverbindungen“ > „Neue Dienstverbindung“ > „GitHub“ > „Autorisieren“ erfolgen. Gewähren Sie Azure Pipelines hier unter „Berechtigungen“ Zugriff auf Ihre Repositorys.

• Wenn sich das Repository im persönlichen GitHub-Konto einer anderen Person befindet, muss sich diese Person mindestens einmal über OAuth mit ihren persönlichen GitHub-Kontoanmeldeinformationen bei GitHub authentifizieren. Dies kann in den Azure DevOps-Projekteinstellungen unter „Pipelines“ > „Dienstverbindungen“ > „Neue Dienstverbindung“ > „GitHub“ > „Autorisieren“ erfolgen. Die andere Person muss Azure Pipelines hier unter „Berechtigungen“ Zugriff auf ihre Repositorys gewähren. Sie müssen in den Einstellungen des Repositorys unter „Mitarbeiter“ als Mitarbeiter*in hinzugefügt werden. Akzeptieren Sie die Einladung über den Link, der Ihnen per E-Mail gesendet wird.

• Wenn sich das Repository in einer GitHub-Organisation in Ihrem Besitz befindet, authentifizieren Sie sich mindestens einmal über OAuth mit Ihren persönlichen GitHub-Kontoanmeldeinformationen bei GitHub. Dies kann in den Azure DevOps-Projekteinstellungen unter „Pipelines“ > „Dienstverbindungen“ > „Neue Dienstverbindung“ > „GitHub“ > „Autorisieren“ erfolgen. Gewähren Sie Azure Pipelines hier unter „Organisationszugriff“ Zugriff auf Ihre Organisation. Sie müssen als Mitarbeiter*in hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter „Mitarbeiter und Teams“ hinzugefügt werden.

• Wenn sich das Repository in einer GitHub-Organisation im Besitz einer anderen Person befindet, muss sich ein GitHub-Organisationsbesitzer mindestens einmal über OAuth mit seinen persönlichen GitHub-Kontoanmeldeinformationen bei GitHub authentifizieren. Dies kann in den Azure DevOps-Projekteinstellungen unter „Pipelines“ > „Dienstverbindungen“ > „Neue Dienstverbindung“ > „GitHub“ > „Autorisieren“ erfolgen. Der Organisationsbesitzer muss Azure Pipelines hier unter „Organisationszugriff“ Zugriff auf die Organisation gewähren. Sie müssen als Mitarbeiter*in hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter „Mitarbeiter und Teams“ hinzugefügt werden. Akzeptieren Sie die Einladung über den Link, der Ihnen per E-Mail gesendet wird.

Widerrufen des OAuth-Zugriffs

Wenn Sie die Autorisierung von Azure Pipelines für die Verwendung von OAuth widerrufen und die weitere Verwendung verhindern möchten, verwenden Sie OAuth Apps in Ihren GitHub-Einstellungen. Sie können OAuth auch aus der Liste der GitHub-Dienstverbindungen in Ihren Azure DevOps-Projekteinstellungen löschen.

Authentifizierung über persönliches Zugriffstoken (PAT)

Persönliche Zugriffstoken (Personal Access Tokens, PATs) sind effektiv identisch mit OAuth, aber Sie können steuern, welche Berechtigungen Azure Pipelines gewährt werden. Builds und GitHub-Statusaktualisierungen werden im Namen Ihrer persönlichen GitHub-Identität ausgeführt. Damit Builds weiterhin funktionieren, muss Ihr Repositoryzugriff aktiv bleiben.

Um ein PAT zu erstellen, öffnen Sie Persönliche Zugriffstoken in Ihren GitHub-Einstellungen. Die erforderlichen Berechtigungen sind repo, admin:repo_hook, read:user und user:email. Dies sind die gleichen Berechtigungen, die bei Verwendung von OAuth erforderlich sind. Kopieren Sie das generierte PAT in die Zwischenablage, und fügen Sie es in Ihren Azure DevOps-Projekteinstellungen in eine neue GitHub-Dienstverbindung ein. Damit Sie die Dienstverbindung später zuordnen können, vergeben Sie einen Namen entsprechend Ihrem GitHub-Benutzernamen. Die Verbindung ist in Ihrem Azure DevOps-Projekt zur späteren Verwendung beim Erstellen von Pipelines verfügbar.

Erforderliche Berechtigungen in GitHub

Um eine Pipeline für ein GitHub-Repository mit Continuous Integration- und Pull Request-Triggern zu erstellen, müssen Sie die erforderlichen GitHub-Berechtigungen konfiguriert haben. Andernfalls wird beim Erstellen der Pipeline das Repository nicht in der Repositoryliste angezeigt. Stellen Sie je nach Authentifizierungstyp und Besitz des Repositorys sicher, dass der folgende Zugriff konfiguriert ist.

• Wenn sich das Repository in Ihrem persönlichen GitHub-Konto befindet, muss das PAT über die erforderlichen Zugriffsbereiche unter Persönliche Zugriffstoken verfügen: repo, admin:repo_hook, read:user und user:email.

• Wenn sich das Repository im persönlichen GitHub-Konto einer anderen Person befindet, muss das PAT über die erforderlichen Zugriffsbereiche unter Persönliche Zugriffstoken verfügen: repo, admin:repo_hook, read:user und user:email. Sie müssen in den Einstellungen des Repositorys unter „Mitarbeiter“ als Mitarbeiter*in hinzugefügt werden. Akzeptieren Sie die Einladung über den Link, der Ihnen per E-Mail gesendet wird.

• Wenn sich das Repository in einer GitHub-Organisation in Ihrem Besitz befindet, muss das PAT über die erforderlichen Zugriffsbereiche unter Persönliche Zugriffstoken verfügen: repo, admin:repo_hook, read:user und user:email. Sie müssen als Mitarbeiter*in hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter „Mitarbeiter und Teams“ hinzugefügt werden.

• Wenn sich das Repository in einer GitHub-Organisation im Besitz einer anderen Person befindet, muss das PAT über die erforderlichen Zugriffsbereiche unter Persönliche Zugriffstoken verfügen: repo, admin:repo_hook, read:user und user:email. Sie müssen als Mitarbeiter*in hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter „Mitarbeiter und Teams“ hinzugefügt werden. Akzeptieren Sie die Einladung über den Link, der Ihnen per E-Mail gesendet wird.

Widerrufen des PAT-Zugriffs

Wenn Sie die Autorisierung von Azure Pipelines für die Verwendung eines persönlichen Zugriffstokens widerrufen und die weitere Verwendung verhindern möchten, verwenden Sie Persönliche Zugriffstoken in Ihren GitHub-Einstellungen. Sie können OAuth auch aus der Liste der GitHub-Dienstverbindungen in Ihren Azure DevOps-Projekteinstellungen löschen.

CI-Trigger

Continuous Integration-Trigger (CI) lösen die Ausführung einer Pipeline aus, wenn Sie eine Aktualisierung an die angegebenen Branches pushen oder wenn Sie angegebene Tags pushen.

YAML

YAML-Pipelines werden standardmäßig mit einem CI-Trigger für alle Zweige konfiguriert, es sei denn, die in Azure DevOps Sprint 227 eingeführte Einstellung Impliziten YAML-CI-Trigger deaktivieren ist aktiviert. Die Einstellung Impliziten YAML-CI-Trigger deaktivieren kann auf Unternehmensebene oder auf Projektebene konfiguriert werden. Wenn die Einstellung Impliziten YAML-CI-Trigger deaktivieren aktiviert ist, werden CI-Trigger für YAML-Pipelines nicht aktiviert, wenn die YAML-Pipeline keinen Abschnitt trigger enthält. Standardmäßig ist die Einstellung Impliziten YAML-CI-Trigger deaktivieren nicht aktiviert.

Branches

Sie können mithilfe einer einfachen Syntax steuern, welche Branches CI-Trigger erhalten:

trigger:
- main
- releases/*

Sie können den vollständigen Namen des Branchs (z. B. main) oder einen Platzhalter (z. B. releases/*) angeben. Informationen zur Platzhaltersyntax finden Sie unter Platzhalter.

Hinweis

Sie können keine Variablen in Triggern verwenden, da Variablen zur Laufzeit ausgewertet werden (nachdem der Trigger ausgelöst wurde).

Hinweis

Wenn Sie zum Erstellen von YAML-Dateien Vorlagen verwenden, können Sie Trigger nur in der YAML-Hauptdatei für die Pipeline angeben. In den Vorlagendateien können Sie keine Trigger angeben.

Bei komplexeren Trigger, die exclude oder batch verwenden, müssen Sie die vollständige Syntax verwenden, wie im folgenden Beispiel gezeigt.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Im obigen Beispiel wird die Pipeline ausgelöst, wenn eine Änderung an main oder an einen Releasebranch gepusht wird. Sie wird jedoch nicht ausgelöst, wenn eine Änderung an einem Releasebranch vorgenommen wird, der mit old beginnt.

Wenn Sie eine exclude-Klausel ohne include-Klausel angeben, ist dies gleichbedeutend mit der Angabe von * in der include-Klausel.

Sie können nicht nur Branchnamen in den branches-Listen angeben, sondern auch Trigger basierend auf Tags konfigurieren, indem Sie das folgende Format verwenden:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Wenn Sie keine Trigger angegeben haben und die Einstellung Impliziten YAML-CI-Trigger deaktivieren nicht aktiviert ist, lautet die Standardeinstellung wie folgt:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Wichtig

Wenn Sie einen Trigger angeben, ersetzt dieser den impliziten Standardtrigger, und nur Pushes an Branches, die per Konfiguration explizit eingeschlossen wurden, lösen eine Pipeline aus. Zuerst Einschlüsse verarbeitet, dann werden Ausschlüsse aus dieser Liste entfernt.

Batchverarbeitung von CI-Ausführungen

Wenn viele Teammitglieder häufig Änderungen hochladen, kann es sinnvoll sein, die Anzahl der gestarteten Ausführungen zu verringern. Wenn Sie batch auf true festlegen, wartet das System bei der Ausführung einer Pipeline, bis diese abgeschlossen ist, und startet dann eine weitere Ausführung mit allen Änderungen, die noch nicht kompiliert wurden.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Hinweis

batch wird in Repositoryressourcentriggern nicht unterstützt.

Zur Verdeutlichung dieses Beispiels: Angenommen, ein Push A an main hat dazu geführt, dass die oben genannte Pipeline ausgeführt wurde. Während der Ausführung dieser Pipeline erfolgen die zusätzlichen Pushes B und C im Repository. Diese Aktualisierungen starten nicht sofort neue unabhängige Ausführungen. Nach Abschluss der ersten Ausführung werden jedoch alle Pushes bis zu diesem Zeitpunkt in einem Batch zusammengefasst, und eine neue Ausführung wird gestartet.

Hinweis

Wenn die Pipeline mehrere Aufträge und Stages enthält, sollte die erste Ausführung trotzdem einen finalen Zustand erreichen, indem alle Aufträge und Stages abgeschlossen oder übersprungen werden, bevor die zweite Ausführung gestartet werden kann. Aus diesem Grund ist bei der Verwendung dieses Features in einer Pipeline mit mehreren Stages oder Genehmigungen Vorsicht geboten. Wenn Sie Ihre Builds in solchen Fällen im Batch verarbeiten möchten, empfiehlt es sich, den CI/CD-Prozess (Continuous Integration und Continuous Delivery) in zwei Pipelines aufzuteilen: eine für den Build (mit Batchverarbeitung) und eine für Bereitstellungen.

Paths

Sie können Dateipfade angeben, die ein- oder ausgeschlossen werden sollen.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Wenn Sie Azure DevOps Server 2019.1 oder früher verwenden, müssen Sie beim Angeben von Pfaden explizit festlegen, für welche Branches die Auslösung erfolgen soll. Es ist nicht möglich, eine Pipeline nur mit einem Pfadfilter auszulösen. Sie benötigen auch einen Branchfilter, und die geänderten Dateien, die dem Pfadfilter entsprechen, müssen aus einem Branch stammen, der dem Branchfilter entspricht. Wenn Sie Azure DevOps Server 2020 oder höher verwenden, können Sie branches weglassen, um in Verbindung mit dem Pfadfilter nach allen Branches zu filtern.

Platzhalter werden für Pfadfilter unterstützt. Sie können z. B. alle Pfade einschließen, die mit src/app/**/myapp* übereinstimmen. Beim Angeben von Pfadfiltern können Sie Platzhalterzeichen (**, * oder ?)) verwenden.

• Pfade werden immer relativ zum Stammverzeichnis des Repositorys angegeben.
• Wenn Sie keine Pfadfilter festlegen, wird der Stammordner des Repositorys standardmäßig implizit eingeschlossen.
• Wenn Sie einen Pfad ausschließen, können Sie ihn nicht gleichzeitig einschließen, es sei denn, Sie qualifizieren ihn in einem Ordner auf einer tieferen Ebene. Wenn Sie beispielsweise /tools ausschließen, können Sie /tools/trigger-runs-on-these einschließen.
• Die Reihenfolge der Pfadfilter spielt keine Rolle.
• Bei Pfaden in Git wird die Groß-/Kleinschreibung beachtet. Achten Sie darauf, die gleiche Groß-/Kleinschreibung wie bei den tatsächlichen Ordnern zu verwenden.
• Sie können keine Variablen in Pfaden verwenden, da Variablen zur Laufzeit ausgewertet werden (nachdem der Trigger ausgelöst wurde).

Tags

Sie können nicht nur Tags in den branches-Listen angeben, wie im vorherigen Abschnitt beschrieben, sondern ein- und auszuschließende Tags auch direkt festlegen:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Wenn Sie keine Tagtrigger angeben, lösen Tags standardmäßig keine Pipelines aus.

Wichtig

Wenn Sie Tags in Kombination mit Branchfiltern angeben, wird der Trigger ausgelöst, wenn entweder der Branchfilter oder der Tagfilter übereinstimmt. Wenn ein gepushtes Tag z. B. mit dem Branchfilter übereinstimmt, wird die Pipeline auch dann ausgelöst, wenn das Tag durch den Tagfilter ausgeschlossen ist, da der Push dem Branchfilter entspricht.

Deaktivieren von CI

Deaktivieren des CI-Triggers

Sie können CI-Trigger vollständig deaktivieren, indem Sie trigger: none angeben.

# A pipeline with no CI trigger
trigger: none

Wichtig

Wenn Sie eine Änderung an einen Branch pushen, wird die YAML-Datei in diesem Branch ausgewertet, um zu bestimmen, ob eine CI-Ausführung gestartet werden soll.

Klassisch

Wählen Sie auf der Registerkarte Trigger die Option Continuous Integration aktivieren aus, um diesen Trigger zu aktivieren, wenn der Build ausgeführt werden soll, sobald jemand Code eincheckt.

Batchänderungen

Aktivieren Sie dieses Kontrollkästchen, wenn viele Teammitglieder häufig Änderungen hochladen und Sie die Anzahl der ausgeführten Builds reduzieren möchten. Wenn Sie diese Option auswählen, wartet das System bei der Ausführung eines Builds, bis diese abgeschlossen ist, und reiht dann eine weitere Ausführung mit allen Änderungen, die noch nicht kompiliert wurden, in die Warteschlange ein.

Sie können Änderungen in einem Batch zusammenfassen und gemeinsam kompilieren.

Hinweis

Wenn Sie die Batchverarbeitung mit einer YAML-Pipeline mit mehreren Stages verwenden, muss eine Ausführung einen finalen Zustand erreichen, bevor die nächste Ausführung gestartet werden kann. Dies ist häufig nicht wünschenswert, da eine Pipeline mit mehreren Stages möglicherweise Genehmigungen erfordert und lange Bereitstellungsstages durchläuft. In diesen Fällen empfiehlt es sich, eine der folgenden Lösungen zu verwenden:

• Verwenden Sie keine Batchverarbeitung.
• Teilen Sie die Pipeline in zwei separate Pipelines auf – eine für CI und eine für CD.
• Legen Sie geeignete Bedingungen für Stages fest, damit diese übersprungen werden und eine Ausführung schnell beendet wird.

Branchfilter

Sie können die Branches angeben, in denen Sie Builds auslösen möchten. Wenn Sie Platzhalterzeichen verwenden möchten, geben Sie die Branchspezifikation (z. B. features/modules/*) ein, und drücken Sie dann die EINGABETASTE.

Pfadfilter

Wenn sich Ihr Git-Repository in Azure Repos oder TFS befindet, können Sie auch Pfadfilter angeben, um die Dateien einzuschränken, die einen Build auslösen sollen.

Tipps:

• Pfade werden immer relativ zum Stammverzeichnis des Repositorys angegeben.
• Wenn Sie keine Pfadfilter festlegen, wird der Stammordner des Repositorys standardmäßig implizit eingeschlossen.
• Wenn Sie einen Pfad ausschließen, können Sie ihn nicht gleichzeitig einschließen, es sei denn, Sie qualifizieren ihn in einem Ordner auf einer tieferen Ebene. Wenn Sie beispielsweise /tools ausschließen, können Sie /tools/trigger-runs-on-these einschließen.
• Die Reihenfolge der Pfadfilter spielt keine Rolle.
• Bei Pfaden in Git wird die Groß-/Kleinschreibung beachtet. Achten Sie darauf, die gleiche Groß-/Kleinschreibung wie bei den tatsächlichen Ordnern zu verwenden.

Beispiel

Angenommen, Ihr Build soll durch Änderungen in main und den meisten, aber nicht allen, Ihrer Featurebranches ausgelöst werden. Zudem möchten Sie nicht, dass Builds durch Änderungen an Dateien im Ordner „tools“ ausgelöst werden.

Überspringen von CI für einzelne Commits

Sie können Azure Pipelines auch anweisen, die Ausführung einer Pipeline zu überspringen, die normalerweise von einem Push ausgelöst wird. Schließen Sie einfach [skip ci] in die Meldung oder Beschreibung der Commits ein, die Teil eines Pushs sind, und Azure Pipelines überspringt die Ausführung von CI für diesen Push. Sie können auch eine der folgenden Varianten verwenden.

• [skip ci] oder [ci skip]
• skip-checks: true oder skip-checks:true
• [skip azurepipelines] oder [azurepipelines skip]
• [skip azpipelines] oder [azpipelines skip]
• [skip azp] oder [azp skip]
• ***NO_CI***

Verwenden des Triggertyps in Bedingungen

Es ist ein gängiges Szenario, je nach dem Typ des Triggers, der die Ausführung gestartet hat, verschiedene Schritte, Aufträge oder Stages in Ihrer Pipeline auszuführen. Dazu können Sie die Systemvariable Build.Reason verwenden. Fügen Sie Ihrem Schritt, Ihrem Auftrag oder Ihrer Stage beispielsweise die folgende Bedingung hinzu, um den Schritt, den Auftrag bzw. die Stage von PR-Überprüfungen (Pull Request) auszuschließen.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Verhalten von Triggern beim Erstellen neuer Branches

Es ist eine gängige Vorgehensweise, mehrere Pipelines für ein und dasselbe Repository zu konfigurieren. Sie können beispielsweise eine Pipeline zum Erstellen der Dokumentation für Ihre App und eine weitere zum Kompilieren des Quellcodes verwenden. In jeder dieser Pipelines können Sie CI-Trigger mit entsprechenden Branch- und Pfadfiltern konfigurieren. Möglicherweise möchten Sie, dass beim Pushen einer Aktualisierung eine Pipeline an den Ordner docs und beim Pushen einer Aktualisierung an den Anwendungscode eine andere Pipeline ausgelöst wird. In diesen Fällen müssen Sie wissen, wie die Pipelines ausgelöst werden, wenn ein neuer Branch erstellt wird.

Das Verhalten beim Pushen eines neuen Branches (der den Branchfiltern entspricht) an Ihr Repository ist wie folgt:

• Wenn Ihre Pipeline Pfadfilter enthält, wird sie nur dann ausgelöst, wenn der neue Branch Änderungen an Dateien enthält, die diesem Pfadfilter entsprechen.
• Wenn Ihre Pipeline keine Pfadfilter enthält, wird sie auch dann ausgelöst, wenn keine Änderungen im neuen Branch vorliegen.

Platzhalter

Wenn Sie einen Branch, ein Tag oder einen Pfad angeben, können Sie einen genauen Namen oder einen Platzhalter verwenden. Bei Platzhaltermustern kann * null oder mehr Zeichen und ? einem einzelnen Zeichen entsprechen.

• Wenn Sie Ihr Muster in einer YAML-Pipeline mit * beginnen, müssen Sie es in Anführungszeichen einschließen, z. B "*-releases".
• Für Branches und Tags:
  • Ein Platzhalter kann an einer beliebigen Stelle im Muster stehen.
• Für Pfade:
  • In Azure DevOps Server 2022 und höher – einschließlich Azure DevOps Services – kann ein Platzhalter an jeder Stelle in einem Pfadmuster stehen, und Sie können * oder ? verwenden.
  • In Azure DevOps Server 2020 und früher können Sie * als letztes Zeichen hinzufügen, das Verhalten ist jedoch mit dem bei der Angabe des Verzeichnisnamens selbst identisch. Sie dürfen nicht* in die Mitte eines Pfadfilters einschließen, und Sie dürfen ? nicht verwenden.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR-Trigger (Pull Request)

PR-Trigger (Pull Request) bewirken, dass eine Pipeline immer dann ausgeführt wird, wenn ein Pull Request mit einem der angegebenen Zielbranches geöffnet oder einer solcher Pull Request geändert wird.

YAML

Branches

Beim Überprüfen Ihrer Pull Requests können Sie die Zielverzweigungen angeben. Um z. B. Pull Requests zu überprüfen, die auf main und releases/* ausgerichtet sind, können Sie den folgenden pr-Trigger verwenden.

pr:
- main
- releases/*

Diese Konfiguration startet eine neue Ausführung, wenn zum ersten Mal ein neuer Pull Request erstellt wird, sowie nach jeder Aktualisierung im Pull Request.

Sie können den vollständigen Namen des Branchs (z. B. main) oder einen Platzhalter (z. B. releases/*) angeben.

Hinweis

Sie können keine Variablen in Triggern verwenden, da Variablen zur Laufzeit ausgewertet werden (nachdem der Trigger ausgelöst wurde).

Hinweis

Wenn Sie zum Erstellen von YAML-Dateien Vorlagen verwenden, können Sie Trigger nur in der YAML-Hauptdatei für die Pipeline angeben. In den Vorlagendateien können Sie keine Trigger angeben.

GitHub erstellt einen neuen Verweis (ref), wenn ein Pull Request erstellt wird. Der Verweis zeigt auf einen Mergecommit, bei dem es sich um den gemergten Code zwischen den Quell- und Zielbranches des Pull Requests handelt. Die PR-Überprüfungspipeline erstellt den Commit, auf den dieses ref-Element verweist. Das bedeutet, dass die YAML-Datei, die zum Ausführen der Pipeline verwendet wird, auch ein Merge zwischen dem Quell- und dem Zielbranch ist. Daher können Änderungen, die Sie an der YAML-Datei im Quellbranch des Pull Requests vornehmen, das Verhalten überschreiben, das von der YAML-Datei im Zielbranch definiert wurde.

Wenn in Ihrer YAML-Datei keine pr-Trigger angezeigt werden, sind Pull Request-Überprüfungen automatisch für alle Branches aktiviert, so als ob Sie den folgenden pr-Trigger geschrieben hätten. Diese Konfiguration löst einen Build aus, wenn ein Pull Request erstellt wird und wenn Commits im Quellbranch eines aktiven Pull Requests ausgeführt werden.

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Wichtig

Wenn Sie einen pr-Trigger mit einer Teilmenge von Branches angeben, wird eine Pipeline nur dann ausgelöst, wenn Aktualisierungen an diese Branches gepusht werden.

Für komplexere Trigger, die bestimmte Branches ausschließen müssen, müssen Sie die vollständige Syntax verwenden, wie im folgenden Beispiel gezeigt. In diesem Beispiel werden Pull Requests überprüft, die auf main oder releases/* abzielen, und der Branch releases/old* ist ausgeschlossen.

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Paths

Sie können Dateipfade angeben, die ein- oder ausgeschlossen werden sollen. Beispiel:

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Tipps:

• Azure Pipelines sendet einen neutralen Status zurück an GitHub, wenn entschieden wird, dass aufgrund einer Pfadausschlussregel kein Überprüfungsbuild ausgeführt werden soll. Das ist eine klare Anweisung an GitHub, dass Azure Pipelines die Verarbeitung abgeschlossen hat. Weitere Informationen finden Sie unter Senden eines neutralen Status an GitHub, wenn ein Build übersprungen wird.
• Platzhalter werden jetzt bei Pfadfiltern unterstützt.
• Pfade werden immer relativ zum Stammverzeichnis des Repositorys angegeben.
• Wenn Sie keine Pfadfilter festlegen, wird der Stammordner des Repositorys standardmäßig implizit eingeschlossen.
• Wenn Sie einen Pfad ausschließen, können Sie ihn nicht gleichzeitig einschließen, es sei denn, Sie qualifizieren ihn in einem Ordner auf einer tieferen Ebene. Wenn Sie beispielsweise /tools ausschließen, können Sie /tools/trigger-runs-on-these einschließen.
• Die Reihenfolge der Pfadfilter spielt keine Rolle.
• Bei Pfaden in Git wird die Groß-/Kleinschreibung beachtet. Achten Sie darauf, die gleiche Groß-/Kleinschreibung wie bei den tatsächlichen Ordnern zu verwenden.
• Sie können keine Variablen in Pfaden verwenden, da Variablen zur Laufzeit ausgewertet werden (nachdem der Trigger ausgelöst wurde).
• Azure Pipelines sendet einen neutralen Status zurück an GitHub, wenn entschieden wird, dass aufgrund einer Pfadausschlussregel kein Überprüfungsbuild ausgeführt werden soll.

Mehrere PR-Aktualisierungen

Sie können angeben, ob weitere Aktualisierungen für einen PR aktive Überprüfungsausführungen für diesen PR abbrechen sollen. Der Standardwert lautet true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Überprüfung von Pull Request-Entwürfen

Standardmäßig werden Pull Request-Trigger für Pull Request-Entwürfe sowie für Pull Requests ausgelöst, die zur Überprüfung bereit sind. Um Pull Request-Trigger für Pull Requests zu deaktivieren, legen Sie die Eigenschaft drafts auf false fest.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Deaktivieren der PR-Überprüfung

Sie können die Überprüfung von Pull Requests auch vollständig deaktivieren, indem Sie pr: none angeben.

# no PR triggers
pr: none

Weitere Informationen finden Sie unter PR-Trigger im YAML-Schema.

Hinweis

Wenn Ihr pr-Trigger nicht ausgelöst wird, führen Sie die Schritte zur Problembehandlung in der häufig gestellten Fragen aus.

Klassisch

Wählen Sie den Trigger Pull Request-Überprüfung aus, und aktivieren Sie das Kontrollkästchen Pull Request-Überprüfung aktivieren, um Builds für Pull Requests zu aktivieren.

Sie können Branches angeben, die ein- und ausgeschlossen werden sollen. Wählen Sie im Dropdownmenü einen Branchnamen und dann entsprechend Einschließen oder Ausschließen aus. Für eingeschlossene Branches wird bei jedem Push zu einem Pull Request, der auf diesen Branch ausgerichtet ist, ein Build ausgelöst.

Wenn Sie Änderungen für einen offenen Pull Request an den zugehörigen Quellbranch pushen, können mehrere Pipelines ausgeführt werden:

• Die Pipelines, die über einen PR-Trigger im Zielbranch des Pull Requests verfügen, werden im Mergecommit (der gemergte Code zwischen der Quell- und Zielbranch des Pull Requests) ausgeführt, unabhängig davon, ob gepushte Commits vorhanden sind, deren Meldungen oder Beschreibungen [skip ci] (oder Varianten davon) enthalten.
• Die Pipelines werden durch Änderungen am Quellbranch des Pull Requests ausgelöst, wenn keine gepushten Commits vorhanden sind, deren Meldungen oder Beschreibungen [skip ci] (oder Varianten davon) enthalten. Wenn mindestens ein gepushter Commit [skip ci] enthält, werden die Pipelines nicht ausgeführt.

Nachdem Sie die Pull Requests gemergt haben, führt Azure Pipelines die CI-Pipelines aus, die durch Pushes an den Zielbranch ausgelöst werden, wenn die Meldung oder Beschreibung des Commits [skip ci] (oder eine seiner Varianten) nicht enthält.

Geschützte Branches

Sie können einen Überprüfungsbuild mit jedem Commit oder Pull Request ausführen, der auf einen Branch ausgerichtet ist, und Sie können sogar verhindern, dass Pull Requests gemergt werden, bevor ein Überprüfungsbuild erfolgreich ist.

Um obligatorische Überprüfungsbuilds für ein GitHub-Repository zu konfigurieren, müssen Sie Besitzer*in, Mitarbeiter*in mit der Administratorrolle oder GitHub-Organisationsmitglied mit der Rolle „Schreiben“ sein.

1. Erstellen Sie zunächst eine Pipeline für das Repository, und kompilieren Sie sie mindestens einmal, damit ihr Status an GitHub gesendet wird und GitHub den Namen der Pipeline kennt.

2. Folgen Sie als Nächstes der Dokumentation von GitHub zum Konfigurieren geschützter Branches in den Einstellungen des Repositorys.

   Wählen Sie für die Statusüberprüfung den Namen Ihrer Pipeline in der Liste Statusüberprüfungen aus.

   

Wichtig

Wenn Ihre Pipeline in dieser Liste nicht angezeigt wird, stellen Sie Folgendes sicher:

• Sie verwenden die GitHub-App-Authentifizierung.
• Ihre Pipeline wurde in der letzten Woche mindestens einmal ausgeführt.

Beiträge aus externen Quellen

Wenn es sich bei Ihrem GitHub-Repository um ein Open-Source-Repository handelt, können Sie Ihr Azure DevOps-Projekt öffentlich machen, damit jede*r die Buildergebnisse, Protokolle und Testergebnisse Ihrer Pipeline anzeigen kann, ohne sich anzumelden. Wenn Benutzer*innen außerhalb Ihrer Organisation Ihr Repository forken und Pull Requests übermitteln, können sie den Status von Builds anzeigen, die diese Pull Requests automatisch überprüfen.

Bedenken Sie bei der Verwendung von Azure Pipelines in einem öffentlichen Projekt folgende Aspekte, wenn Sie Beiträgen aus externen Quellen akzeptieren möchten.

• Zugriffsbeschränkungen
• Überprüfen der Beiträge aus Forks
• Wichtige Sicherheitsüberlegungen

Zugriffsbeschränkungen

Beachten Sie die folgenden Zugriffsbeschränkungen, wenn Sie Pipelines in öffentlichen Azure DevOps-Projekten ausführen:

• Geheimnisse: Standardmäßig werden Geheimnisse Ihrer Pipeline nicht für Pull Request-Überprüfungen von Forks verfügbar gemacht. Weitere Informationen finden Sie unter Überprüfen der Beiträge aus Forks.
• Projektübergreifender Zugriff: Alle Pipelines in einem öffentlichen Azure DevOps-Projekt werden mit einem Zugriffstoken ausgeführt, das auf das Projekt beschränkt ist. Pipelines in einem öffentlichen Projekt können nur innerhalb des Projekts auf Ressourcen wie Buildartefakte oder Testergebnisse zugreifen, nicht in anderen Projekten der Azure DevOps-Organisation.
• Azure Artifacts-Pakete: Wenn Ihre Pipelines Zugriff auf Pakete von Azure Artifacts benötigen, müssen Sie dem Konto für den Projektbuilddienst die Berechtigung für den Zugriff auf die Paketfeeds erteilen.

Beiträge aus Forks

Wichtig

Diese Einstellungen wirken sich auf die Sicherheit Ihrer Pipeline aus.

Wenn Sie eine Pipeline erstellen, wird sie automatisch für Pull Requests aus Forks Ihres Repositorys ausgelöst. Sie können dieses Verhalten ändern, müssen dabei aber sorgfältig abwägen, wie es sich auf die Sicherheit auswirkt. So aktivieren oder deaktivieren Sie dieses Verhalten:

1. Wechseln Sie zu Ihrem Azure DevOps-Projekt. Wählen Sie Pipelines aus, suchen Sie Ihre Pipeline, und wählen Sie Bearbeiten aus.
2. Wählen Sie die Registerkarte Trigger aus. Nachdem Sie den Pull Request-Trigger aktiviert haben, aktivieren oder deaktivieren Sie das Kontrollkästchen Pull Requests aus Forks dieses Repositorys erstellen.

In GitHub-Pipelines werden Geheimnisse, die Ihrer Buildpipeline zugeordnet sind, standardmäßig nicht für Pull Request-Builds aus Forks verfügbar gemacht. In GitHub Enterprise Server-Pipelines sind diese Geheimnisse standardmäßig aktiviert. Zu den Geheimnissen gehören:

• Ein Sicherheitstoken mit Zugriff auf Ihr GitHub-Repository
• Folgende Elemente, wenn Ihre Pipeline sie verwendet:
  • Anmeldeinformationen für die Dienstverbindung
  • Dateien aus der Bibliothek mit sicheren Dateien
  • Build-Variablen, die als Geheimnis markiert sind

Um diese Vorsichtsmaßnahme in GitHub-Pipelines zu umgehen, aktivieren Sie das Kontrollkästchen Geheimnisse für Builds aus Forks verfügbar machen. Beachten Sie die Auswirkungen dieser Einstellung auf die Sicherheit.

Hinweis

Wenn Sie den Zugriff von Forkbuilds auf Geheimnisse aktivieren, schränkt Azure Pipelines standardmäßig das Zugriffstoken ein, das für Forkbuilds verwendet wird. Für dieses Token ist der Zugriff auf offene Ressourcen weiter eingeschränkt als bei normalen Zugriffstoken. Um Forkbuilds die gleichen Berechtigungen wie regulären Builds zu gewähren, aktivieren Sie die Einstellung Forkbuilds mit den gleichen Berechtigungen erstellen wie reguläre Builds.

Weitere Informationen finden Sie unter Repositoryschutz – Forks.

Mithilfe des Steuerelements Erstellung von Pull Requests aus geforkten GitHub-Repositorys begrenzen können Sie zentral definieren, wie Pipelines PRs aus geforkten GitHub-Repositorys erstellen. Es ist auf Organisations- und Projektebene verfügbar. Sie haben folgende Möglichkeiten:

• Deaktivieren von „Pull Requests aus geforkten Repositorys erstellen“
• Pull Requests aus geforkten Repositorys sicher erstellen
• Regeln zum Erstellen von Pull Requests aus geforkten Repositorys anpassen

Ab Sprint 229 erstellt Azure Pipelines keine Pull Requests mehr aus geforkten GitHub-Repositorys, um die Sicherheit Ihrer Pipelines zu verbessern. Für neue Projekte und Organisationen ist die Einstellung Pull-Request-Erstellung auf geforkte GitHub-Repositorys beschränken standardmäßig auf Pull-Request-Erstellung aus geforkten Repositorys deaktivieren festgelegt.

Wenn Sie die Option Pull Requests aus geforkten Repositorys sicher erstellen auswählen, können alle Pipelines, organisations- oder projektweit, keine Geheimnisse für Builds von PRs aus geforkten Repositorys verfügbar machen, diesen Builds nicht dieselben Berechtigungen wie normale Builds geben, und sie müssen durch einen PR-Kommentar ausgelöst werden. Projekte können trotzdem entscheiden, dass Pipelines solche PRs nicht erstellen dürfen.

Wenn Sie die Option Anpassen auswählen, können Sie definieren, wie Pipelineeinstellungen eingeschränkt werden sollen. Sie können beispielsweise sicherstellen, dass alle Pipelines einen Kommentar benötigen, um einen PR aus einem geforkten GitHub-Repository zu erstellen, wenn der PR Nicht-Teammitgliedern und Nicht-Mitwirkenden gehört. Sie können jedoch zulassen, dass sie Geheimnisse für solche Builds verfügbar machen. Projekte können entscheiden, dass Pipelines solche PRs nicht erstellen oder sicher erstellen oder noch restriktivere Einstellungen haben, als auf Organisationsebene angegeben werden.

Das Steuerelement ist für vorhandene Organisationen deaktiviert. Ab September 2023 haben neue Organisationen Pull Request aus geforkten Repositorys sicher erstellen standardmäßig aktiviert.

Wichtige Sicherheitsüberlegungen

GitHub-Benutzer*innen können Ihr Repository forken, ändern und einen Pull Request erstellen, um Änderungen an Ihrem Repository vorzuschlagen. Dieser Pull Request kann schädlichen Code enthalten, der als Teil Ihres ausgelösten Builds ausgeführt werden soll. Solcher Code kann auf folgende Weise Schaden verursachen:

• Geheimnisse in Ihrer Pipeline können offengelegt werden. Um dieses Risiko zu minimieren, aktivieren Sie das Kontrollkästchen Geheimnisse für Builds aus Forks verfügbar machen nicht, wenn Ihr Repository öffentlich ist oder nicht vertrauenswürdige Benutzer*innen Pull Request senden können, die automatisch Builds auslösen. Diese Option ist standardmäßig deaktiviert.

• Der Computer, auf dem der Agent ausgeführt wird, kann angegriffen werden, um Code oder Geheimnisse aus anderen Pipelines zu stehlen. So minimieren Sie dieses Risiko:

  • Verwenden Sie einen von Microsoft gehosteten Agentpool, um Pull Requests aus Forks zu erstellen. Von Microsoft gehostete Agentcomputer werden nach Abschluss eines Builds sofort gelöscht, sodass ein Angriff auf einen solchen Computer keine dauerhaften Auswirkungen nach sich zieht.

  • Wenn Sie einen selbstgehosteten Agent verwenden müssen, speichern Sie keine Geheimnisse, und führen Sie keine anderen Builds und Releases aus, die Geheimnisse im selben Agent verwenden, es sei denn, Ihr Repository ist privat und Sie vertrauen den Pull Request-Ersteller*innen.

Kommentartrigger

Beitragende zu Repositorys können einen Pull Request kommentieren, damit eine Pipeline manuell ausgeführt wird. Hier finden Sie einige häufige Gründe für eine solche Vorgehensweise:

• Sie möchten nicht, dass Pull Requests von unbekannten Benutzer*innen automatisch kompiliert werden, da die Änderungen erst überprüft werden sollen. Eines Ihrer Teammitglieder soll zuerst den Code überprüfen und dann die Pipeline ausführen. Dies ist eine gängige Sicherheitsmaßnahme beim Kompilieren von aus geforkten Repositorys stammendem Code.
• Sie möchten eine optionale Testsuite oder einen weiteren Überprüfungsbuild ausführen.

Um Kommentartrigger zu aktivieren, müssen Sie die folgenden beiden Schritte ausführen:

1. Aktivieren Sie Pull Request-Trigger für Ihre Pipeline, und stellen Sie sicher, dass Sie den Zielbranch nicht ausgeschlossen haben.
2. Bearbeiten Sie Ihre Pipeline im Azure Pipelines-Webportal, und wählen Sie Weitere Aktionen > Trigger aus. Aktivieren Sie dann unter Pull Request-Überprüfung die Option Vor dem Erstellen eines Pull Requests Kommentar eines Teammitglieds anfordern.
   • Wählen Sie Bei allen Pull Requests aus, um den Kommentar eines Teammitglieds vor dem Erstellen einer Pull Requests anzufordern. Bei diesem Workflow überprüft ein Teammitglied den Pull Request und löst den Build mit einem Kommentar aus, wenn der Pull Request als sicher eingestuft wurde.
   • Wählen Sie Nur für Pull Requests von Nicht-Teammitgliedern, um den Kommentar eines Teammitglieds nur dann zu verlangen, wenn ein Pull Request von einem Nicht-Teammitglied erstellt wurde. In diesem Workflow ist bei Pull Requests von Teammitgliedern keine Überprüfung durch ein zweites Teammitglied erforderlich, damit ein Build ausgelöst wird.

Mit diesen beiden Änderungen wird der Überprüfungsbuild eines Pull Requests nicht automatisch ausgelöst, es sei denn, Nur für Pull Requests von Nicht-Teammitgliedern ist ausgewählt und der PR stammt von einem Teammitglied. Nur Repositorybesitzer*innen und Mitarbeiter*innen mit der Berechtigung „Schreiben“ können den Build durch Kommentieren des Pull Requests mit /AzurePipelines run oder /AzurePipelines run <pipeline-name> auslösen.

Die folgenden Befehle können in Kommentaren an Azure Pipelines ausgegeben werden:

Befehl	Ergebnis
/AzurePipelines help	Für alle unterstützten Befehle wird Hilfe angezeigt.
/AzurePipelines help <command-name>	Für den angegebenen Befehl wird Hilfe angezeigt.
/AzurePipelines run	Alle Pipelines, die diesem Repository zugeordnet sind und deren Trigger diesen Pull Request nicht ausschließen, werden ausgeführt.
/AzurePipelines run <pipeline-name>	Die angegebene Pipeline wird ausgeführt, es sei denn, ihre Trigger schließen diesen Pull Request aus.

Hinweis

Aus Platzgründen können Sie Kommentare mithilfe von /azp statt /AzurePipelines einfügen.

Wichtig

Antworten auf diese Kommentare werden nur dann in der Diskussion zum Pull Request angezeigt, wenn Ihre Pipeline die Azure Pipelines-GitHub-App verwendet.

Behandeln von Problemen mit Pull Request-Kommentartriggern

Wenn Sie über die erforderlichen Repositoryberechtigungen verfügen, Ihre Kommentare aber keine Pipelines auslösen, stellen Sie sicher, dass Ihre Mitgliedschaft in der Organisation des Repositorys auf öffentlich festgelegt ist, oder fügen Sie sich direkt als Repositorymitarbeiter*in hinzu. Pipelines können Mitglieder einer privaten Organisation nicht erkennen, es sei denn, die Mitglieder sind direkte Mitarbeiter*innen oder gehören zu einem Team, das als direkter Mitarbeiter festgelegt ist. Hier können Sie Ihre Mitgliedschaft in einer GitHub-Organisation von „privat“ zu „öffentlich“ ändern (ersetzen Sie Your-Organization durch den Namen Ihrer Organisation): https://github.com/orgs/Your-Organization/people.

Informationsausführungen

Eine Informationsausführung teilt Ihnen mit, dass Azure DevOps den Quellcode einer YAML-Pipeline nicht abrufen konnte. Der Quellcodeabruf erfolgt als Reaktion auf externe Ereignisse, z. B. einen gepushten Commit. Der Abruf erfolgt auch als Reaktion auf interne Trigger, z. B. um zu überprüfen, ob Codeänderungen vorliegen und eine geplante Ausführung gestartet werden muss. Beim Quellcodeabruf können aus mehreren Gründen Fehler auftreten – ein häufiger Grund ist beispielsweise eine Anforderungsdrosselung durch den Git-Repositoryanbieter. Das Vorhandensein einer Informationsausführung bedeutet nicht unbedingt, dass Azure DevOps die Pipeline ausführen wird.

Im folgenden Screenshot sehen Sie ein Beispiel für eine Informationsausführung.

Sie können eine Informationsausführung an den folgenden Attributen erkennen:

• Der Status lautet Canceled.
• Die Dauer beträgt < 1s.
• Der Ausführungsname enthält einen der folgenden Texte:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• Der Ausführungsname enthält im Allgemeinen den Bitbucket-/GitHub-Fehler, der zu einem Fehler beim Laden der YAML-Pipeline führte.
• Es sind keine Stages/Aufträge/Schritte vorhanden.

Erfahren Sie mehr über Informationsausführungen.

Auschecken

Wenn eine Pipeline ausgelöst wird, pullt Azure Pipelines Ihren Quellcode aus dem Azure Repos-Git-Repository. Sie können verschiedene Aspekte dieses Vorgangs steuern.

Hinweis

Wenn Sie einen Check-Out-Schritt in Ihre Pipeline einschließen, wird der folgende Befehl ausgeführt: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Falls dies nicht Ihren Anforderungen entspricht, können Sie den integrierten Check-Out durch Angabe von checkout: none ausschließen und dann eine Skriptaufgabe verwenden, um Ihren eigenen Check-Out-Vorgang durchzuführen.

Bevorzugte Git-Version

Der Windows-Agent verfügt über eine eigene Git-Version. Wenn Sie Ihre eigene Git-Version bereitstellen möchten, anstatt die enthaltene Version zu verwenden, legen Sie System.PreferGitFromPath auf true fest. Diese Einstellung ist bei Nicht-Windows-Agents immer auf „true“ festgelegt.

Check-Out-Pfad

YAML

Wenn Sie ein einzelnes Repository auschecken, wird Ihr Quellcode standardmäßig in ein Verzeichnis namens s ausgecheckt. Für YAML-Pipelines können Sie dies ändern, indem Sie checkout mit einem path-Wert angeben. Der angegebene Pfad ist relativ zu $(Agent.BuildDirectory). Beispiel: Wenn der Wert für den Check-Out-Pfad mycustompath lautet und $(Agent.BuildDirectory) auf C:\agent\_work\1 festgelegt ist, wird der Quellcode in C:\agent\_work\1\mycustompath ausgecheckt.

Wenn Sie mehrere checkout-Schritte verwenden, mehrere Repositorys auschecken und den Ordner nicht explizit mit path angeben, wird jedes Repository in einem Unterordner von s abgelegt, der nach dem Repository benannt ist. Wenn Sie zum Beispiel zwei Repositorys mit den Namen tools und code auschecken, wird der Quellcode in C:\agent\_work\1\s\tools und C:\agent\_work\1\s\code ausgecheckt.

Beachten Sie, dass der Wert für den Check-Out-Pfad nicht auf Verzeichnisebenen oberhalb von $(Agent.BuildDirectory) festgelegt werden kann. Daher führt die Angabe von path\..\anotherpath zu einem gültigen Check-Out-Pfad (d. h. C:\agent\_work\1\anotherpath), die Angabe von ..\invalidpath jedoch nicht (d. h. C:\agent\_work\invalidpath).

Sie können die path-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Klassisch

Diese Einstellung kann im klassischen Editor nicht konfiguriert werden. Ihr Quellcode wird in ein Verzeichnis namens s ausgecheckt, das relativ zu $(Agent.BuildDirectory) ist. Beispiel: Wenn $(Agent.BuildDirectory) auf C:\agent\_work\1 festgelegt ist, wird der Quellcode in C:\agent\_work\1\mycustompathausgecheckt.

Submodule

YAML

Sie können die Einstellung submodules im Check-Out-Schritt Ihrer Pipeline konfigurieren, wenn Sie Dateien aus Submodulen herunterladen möchten.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Klassisch

Sie können die Einstellung Submodule in den Einstellungen der Aufgabe Quellen abrufen Ihrer Pipeline konfigurieren, wenn Sie Dateien aus Submodulen herunterladen möchten.

Die Buildpipeline checkt Ihre Git-Submodule aus, sofern Folgendes auf sie zutrifft:

• Nicht authentifiziert: Ein öffentliches, nicht authentifiziertes Repository, für das keine Anmeldeinformationen zum Klonen oder Abrufen erforderlich sind.

• Authentifiziert:

  • Ist im selben Projekt enthalten wie das oben angegebene Azure Repos-Git-Repository. Die Anmeldeinformationen, die der Agent zum Abrufen der Quellen aus dem Hauptrepository verwendet, werden auch zum Abrufen der Quellen für Submodule verwendet.

  • Wird mithilfe einer URL relativ zum Hauptrepository hinzugefügt. Beispiel:

    • Folgendes Submodul würde ausgecheckt: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      In diesem Beispiel verweist das Submodul auf ein Repository (FabrikamFiber) in derselben Azure DevOps-Organisation, aber in einem anderen Projekt (FabrikamFiberProject). Die Anmeldeinformationen, die der Agent zum Abrufen der Quellen aus dem Hauptrepository verwendet, werden auch zum Abrufen der Quellen für Submodule verwendet. Dies setzt voraus, dass das Auftragszugriffstoken Zugriff auf das Repository im zweiten Projekt hat. Wenn Sie das Auftragszugriffstoken wie im obigen Abschnitt erläutert eingeschränkt haben, ist dies nicht möglich. Sie können dem Auftragszugriffstoken den Zugriff auf das Repository im zweiten Projekt erlauben, indem Sie entweder (a) explizit Zugriff auf das Konto des Projektbuilddiensts im zweiten Projekt gewähren oder (b) sammlungsbezogene Zugriffstoken anstelle projektbezogener Token für die gesamte Organisation verwenden. Weitere Informationen zu diesen Optionen und ihren Auswirkungen auf die Sicherheit finden Sie unter Zugreifen auf Repositorys, Artefakte und andere Ressourcen.

    • Folgendes Submodul würde nicht ausgecheckt: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternative zur Verwendung der Option „Submodule auschecken“

In einigen Fällen kann die Option Submodule auschecken nicht verwendet werden. Möglicherweise liegt ein Szenario vor, in dem für den Zugriff auf die Submodule andere Anmeldeinformationen benötigt werden. Dies kann beispielsweise der Fall sein, wenn Ihr Hauptrepository und die Repositorys der Submodule nicht in derselben Azure DevOps-Organisation gespeichert sind oder Ihr Auftragszugriffstoken keinen Zugriff auf das Repository in einem anderen Projekt hat.

Wenn die Option Submodule auschecken nicht verwendet werden kann, können Sie stattdessen einen benutzerdefinierten Skriptschritt zum Abrufen von Submodulen verwenden. Rufen Sie zunächst ein persönliches Zugriffstoken (Personal Access Token, PAT) ab, und stellen Sie ihm pat: voran. Als Nächstes codieren Sie diese mit einem Präfix versehene Zeichenfolge mit Base64, um ein Standardauthentifizierungstoken zu erstellen. Abschließend fügen Sie Ihrer Pipeline dieses Skript hinzu:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Ersetzen Sie <BASE64_ENCODED_STRING> durch Ihre Base64-codierte pat:token-Zeichenfolge.

Verwenden Sie eine Geheimnisvariable in Ihrem Projekt oder Ihrer Buildpipeline, um das von Ihnen generierte Standardauthentifizierungstoken speichern. Verwenden Sie diese Variable, um das Geheimnis im obigen Git-Befehl aufzufüllen.

Hinweis

F: Warum kann ich keine Git-Anmeldeinformationsverwaltung für den Agent verwenden? A: Es ist in der Regel nicht effizient, die Anmeldeinformationen für Submodule in einer Git-Anmeldeinformationsverwaltung zu speichern, die auf Ihrem privaten Build-Agent installiert ist, da Sie möglicherweise bei jeder Aktualisierung des Submoduls zur erneuten Eingabe der Anmeldeinformationen aufgefordert werden. Dies ist bei automatisierten Builds nicht wünschenswert, wenn keine Interaktion mit den Benutzer*innen möglich ist.

Synchronisieren von Tags

Wichtig

Das Feature für Synchronisierungstags wird in Azure Repos Git mit Azure DevOps Server 2022.1 und höher unterstützt.

Im Check-Out-Schritt wird die Option --tags beim Abrufen des Inhalts eines Git-Repositorys verwendet. Dies bewirkt, dass der Server alle Tags und alle Objekte abruft, auf die von diesen Tags verwiesen wird. Dadurch verlängert sich die Ausführungsdauer der Aufgabe in einer Pipeline, insbesondere wenn es sich um ein umfangreiches Repository mit vielen Tags handelt. Darüber hinaus synchronisiert der Check-Out-Schritt Tags, auch wenn Sie die Option für flaches Abrufen aktivieren, was dem eigentlichen Zweck dieser Option widerspricht. Um die Menge der Daten zu reduzieren, die aus einem Git-Repository abgerufen oder gepullt werden, hat Microsoft eine neue Check-Out-Option hinzugefügt, mit der das Verhalten bei der Synchronisierung von Tags gesteuert werden kann. Diese Option ist sowohl in klassischen als auch in YAML-Pipelines verfügbar.

Ob Tags beim Auschecken eines Repositorys synchronisiert werden, können Sie in YAML durch Festlegen der fetchTags-Eigenschaft und in der Benutzeroberfläche durch Festlegen der Einstellung Tags synchronisieren konfigurieren.

YAML

Sie können die fetchTags-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

In YAML legen Sie zum Konfigurieren der Einstellung die fetchTags-Eigenschaft fest.

steps:
- checkout: self
  fetchTags: true

Sie können diese Einstellung auch mit der Option Tags synchronisieren in der Benutzeroberfläche für die Pipelineeinstellungen konfigurieren.

1. Bearbeiten Sie Ihre YAML-Pipeline, und wählen Sie Weitere Aktionen > Trigger aus.

   

2. Wählen Sie YAML und dann Quellen abrufen aus.

   

3. Konfigurieren Sie die Einstellung Tags synchronisieren.

   

Hinweis

Wenn Sie fetchTags in Ihrem checkout-Schritt explizit festlegen, hat diese Einstellung Vorrang vor der Einstellung, die in der Benutzeroberfläche mit den Pipelineeinstellungen konfiguriert ist.

Klassisch

Sie können die Einstellung Tags synchronisieren in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline konfigurieren.

Standardverhalten

• Für vorhandene Pipelines, die vor dem Release von Azure DevOps Sprint 209 vom September 2022 erstellt wurden, bleibt das Standardverhalten für die Synchronisierung von Tags unverändert und entspricht weiterhin dem Verhalten vor dem Hinzufügen der Optionen für Tags synchronisieren (d. h. true).
• Für neue Pipelines, die nach dem Release von Azure DevOps-Sprint 209 erstellt wurden, ist false der Standardwert für die Synchronisierung von Tags.

Hinweis

Wenn Sie fetchTags in Ihrem checkout-Schritt explizit festlegen, hat diese Einstellung Vorrang vor der Einstellung, die in der Benutzeroberfläche mit den Pipelineeinstellungen konfiguriert ist.

Flaches Abrufen

Sie können Downloads bei Bedarf auf eine bestimmte Zeitspanne in der Vergangenheit beschränken. Dies führt effektiv zu git fetch --depth=n. Bei einem großen Repository kann diese Option die Effizienz Ihrer Buildpipeline verbessern. Ihr Repository kann groß sein, wenn es schon lange verwendet wird und einen umfangreichen Verlauf aufweist. Das Repository kann auch groß sein, wenn Sie große Dateien hinzugefügt und später gelöscht haben.

Wichtig

Für neue Pipelines, die nach dem Azure DevOps-Sprint 209-Update vom September 2022 erstellt wurden, ist Flaches Abrufen standardmäßig aktiviert und mit der Tiefe 1 konfiguriert. Davor war das flache Abrufen nicht die Standardeinstellung. Um Ihre Pipeline zu überprüfen, sehen Sie sich wie im folgenden Abschnitt beschrieben die Einstellung Flaches Abrufen in der Benutzeroberfläche der Pipelineeinstellungen an.

YAML

Sie können die fetchDepth-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Sie können die Abruftiefe auch konfigurieren, indem Sie die Option Tiefe für flaches Abrufen in der Benutzeroberfläche mit den Pipelineeinstellungen festlegen.

1. Bearbeiten Sie Ihre YAML-Pipeline, und wählen Sie Weitere Aktionen > Trigger aus.

   

2. Wählen Sie YAML und dann Quellen abrufen aus.

   

3. Konfigurieren Sie die Einstellung Flaches Abrufen. Deaktivieren Sie Flaches Abrufen, um das flache Abrufen zu deaktivieren, oder aktivieren Sie das Kontrollkästchen, und geben Sie eine Tiefe ein, um das flache Abrufen zu aktivieren.

   

Hinweis

Wenn Sie fetchDepth in Ihrem checkout-Schritt explizit festlegen, hat diese Einstellung Vorrang vor der Einstellung, die in der Benutzeroberfläche mit den Pipelineeinstellungen konfiguriert ist. Die Einstellung fetchDepth: 0 ruft den gesamten Verlauf ab und überschreibt die Einstellung Flaches Abrufen.

Klassisch

Sie können die Einstellung Flaches Abrufen in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline konfigurieren.

In diesen Fällen hilft diese Option Ihnen dabei, Netzwerk- und Speicherressourcen zu schonen. Gleichzeitig können Sie möglicherweise Zeit sparen. Eine Zeitersparnis ist nicht immer möglich, weil der Server in einigen Situationen Zeit benötigt, um die herunterzuladenden Commits für die von Ihnen angegebene Tiefe zu berechnen.

Hinweis

Beim Starten der Pipeline wird der zu erstellende Branch in eine Commit-ID aufgelöst. Anschließend ruft der Agent den Branch ab und checkt den gewünschten Commit aus. Es gibt ein kleines Zeitfenster zwischen der Auflösung eines Branchs in eine Commit-ID und dem Zeitpunkt, an dem der Agent den Check-Out durchführt. Wenn der Branch umgehend aktualisiert wird und Sie einen sehr kleinen Wert für „Flaches Abrufen“ festlegen, ist der Commit möglicherweise nicht vorhanden, wenn der Agent versucht, ihn auszuchecken. Erhöhen Sie in diesem Fall die Einstellung der Tiefe für das „Flaches Abrufen“.

Keine Synchronisierung von Quellen

Möglicherweise möchten Sie das Abrufen neuer Commits überspringen. Diese Option kann in folgenden Fällen nützlich sein:

• Git-Initialisierung, -Konfiguration und -Abruf mit Ihren eigenen, benutzerdefinierten Optionen

• Verwenden einer Buildpipeline, um nur Automatisierungen (z. B. einige Skripts) auszuführen, die keinen Code in der Versionskontrolle benötigen

YAML

Sie können die Einstellung Quellen nicht synchronisieren im Check-Out-Schritt Ihrer Pipeline konfigurieren, indem Sie checkout: none festlegen.

steps:
- checkout: none  # Don't sync sources

Klassisch

Wählen Sie in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline die Einstellung Quellen nicht synchronisieren aus.

Hinweis

Wenn Sie diese Option verwenden, überspringt der Agent auch die Ausführung von Git-Befehlen, die das Repository bereinigen.

Bereinigen von Builds

Es gibt verschiedene Möglichkeiten zum Bereinigen des Arbeitsverzeichnisses Ihres selbstgehosteten Agents, bevor ein Build ausgeführt wird.

Im Allgemeinen sollten Sie das Repository nicht bereinigen, um die Leistung Ihrer selbstgehosteten Agents zu erhöhen. Um die beste Leistung zu erzielen, sollten Sie in diesem Fall auch sicherstellen, dass die Erstellung inkrementell erfolgt. Deaktivieren Sie dazu die Option Bereinigen der Aufgabe oder des Tools, die bzw. das Sie zur Builderstellung verwenden.

Wenn Sie das Repository bereinigen müssen (z. B. um Probleme zu vermeiden, die durch verbleibende Dateien aus einem früheren Build verursacht werden), haben Sie folgende Möglichkeiten.

Hinweis

Die Bereinigung ist nicht effizient, wenn Sie einen von Microsoft gehosteten Agent verwenden, da jedes Mal ein neuer Agent abgerufen wird.

YAML

Sie können die clean-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Wenn clean auf true festgelegt ist, macht die Buildpipeline alle Änderungen in $(Build.SourcesDirectory) rückgängig. Insbesondere werden die folgenden Git-Befehle ausgeführt, bevor der Quellcode abgerufen wird.

git clean -ffdx
git reset --hard HEAD

Weitere Möglichkeiten bietet die Konfiguration der workspace-Einstellung eines Auftrags.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Dort erhalten Sie die folgenden Optionen zum Bereinigen.

• outputs: Dies ist der gleiche Vorgang wie bei der Einstellung „clean“ in der oben beschriebenen Check-Out-Aufgabe, zusätzlich wird $(Build.BinariesDirectory) gelöscht und neu erstellt. Beachten Sie, dass $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) unabhängig von diesen Einstellungen immer gelöscht und vor jedem Build neu erstellt werden.

• resources: Löscht $(Build.SourcesDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

• all: Löscht $(Agent.BuildDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

Klassisch

Wählen Sie in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline die Einstellung Bereinigen und dann eine der folgenden Optionen aus.

• Quellen: Die Buildpipeline macht alle Änderungen in $(Build.SourcesDirectory) rückgängig. Insbesondere werden die folgenden Git-Befehle ausgeführt, bevor der Quellcode abgerufen wird.

  git clean -ffdx
  git reset --hard HEAD
  

• Quellen und Ausgabeverzeichnis: Dies ist der gleiche Vorgang wie bei der oben beschriebenen Option Quellen, zusätzlich wird $(Build.BinariesDirectory) gelöscht und neu erstellt. Beachten Sie, dass $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) unabhängig von diesen Einstellungen immer gelöscht und vor jedem Build neu erstellt werden.

• Quellenverzeichnis: Löscht $(Build.SourcesDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

• Alle Buildverzeichnisse: Löscht $(Agent.BuildDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

Bezeichnen von Quellen

Vielleicht möchten Sie Ihre Quellcodedateien mit Bezeichnungen versehen, damit Ihr Team leicht erkennen kann, welche Version der jeweiligen Dateien im fertigen Build enthalten ist. Sie können außerdem festlegen, ob der Quellcode für alle Builds oder nur für erfolgreiche Builds mit Bezeichnungen versehen werden soll.

YAML

Sie können diese Einstellung derzeit im klassischen Editor konfigurieren, nicht aber in YAML. Wenn Sie eine YAML-Pipeline bearbeiten, können Sie auf den klassischen Editor zugreifen, indem Sie im Menü des YAML-Editors einen Trigger auswählen.

Wählen Sie im klassischen Editor YAML und dann die Aufgabe Quellen abrufen aus, und konfigurieren Sie anschließend die gewünschten Eigenschaften.

Klassisch

Sie können die Einstellung Tagquellen in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline konfigurieren.

Im Tagformat können Sie benutzerdefinierte und vordefinierte Variablen mit dem Bereich „Alle“ verwenden. Ein Beispiel:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Die ersten vier Variablen sind vordefiniert. My.Variable kann von Ihnen auf der Registerkarte „Variablen“ definiert werden.

Die Buildpipeline versieht Ihre Quellen mit einem Git-Tag.

Einige Buildvariablen können einen Wert ergeben, der keine gültige Bezeichnung ist. Beispielsweise können Variablen wie $(Build.RequestedFor) und $(Build.DefinitionName) Leerzeichen enthalten. Wenn der Wert Leerzeichen enthält, wird das Tag nicht erstellt.

Nachdem die Quellen von Ihrer Buildpipeline mit einer Bezeichnung versehen wurden, wird dem fertigen Build automatisch ein Artefakt mit dem Git-Verweis refs/tags/{tag} hinzugefügt. Das bietet Ihrem Team zusätzliche Nachvollziehbarkeit und eine benutzerfreundlichere Möglichkeit, vom Build zum kompilierten Code zu navigieren. Das Tag wird als Buildartefakt betrachtet, da es durch den Build erzeugt wird. Wird der Build entweder manuell oder über eine Aufbewahrungsrichtlinie gelöscht, wird auch das Tag gelöscht.

Vordefinierte Variablen

Wenn Sie ein GitHub-Repository erstellen, sind die meisten der vordefinierten Variablen für Ihre Aufträge verfügbar. Da Azure Pipelines jedoch die Identität von Benutzer*innen nicht erkennt, die eine Aktualisierung in GitHub vornimmt, sind die folgenden Variablen auf die Systemidentität statt auf die Benutzeridentität festgelegt:

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Statusaktualisierungen

Es gibt zwei Arten von Status, die Azure Pipelines an GitHub zurücksendet: grundlegende Status und GitHub-Prüfausführungen. GitHub-Prüfungen sind nur für GitHub-Apps verfügbar.

Pipelinestatus werden an verschiedenen Stellen auf der GitHub-Benutzeroberfläche angezeigt.

• Für PRs werden sie auf der Registerkarte mit „PR-Konversationen“ angezeigt.
• Bei einzelnen Commits können Sie die Status anzeigen, indem Sie nach der Commitzeit auf der Registerkarte „Commit“ des Repositorys mit dem Mauszeiger auf das Statuszeichen zeigen.

PAT- oder OAuth-GitHub-Verbindungen

Bei Pipelines mit PAT- oder OAuth-GitHub-Verbindungen werden Status an den Commit/PR zurückgesendet, der die Ausführung ausgelöst hat. Zum Veröffentlichen solcher Aktualisierungen wird die GitHub-Status-API verwendet. Diese Status enthalten nur wenige Informationen: Pipelinestatus (Fehler, Erfolg), URL zum Verknüpfen mit der Buildpipeline und eine kurze Beschreibung des Status.

Status für PAT- oder OAuth-GitHub-Verbindungen werden nur auf Ausführungsebene gesendet. Anders gesagt: für eine gesamte Ausführung kann ein einzelner Status aktualisiert werden. Wenn Sie eine Ausführung mehrere Aufträge enthält, können Sie nicht für jeden Auftrag einen separaten Status senden. Mehrere Pipelines können jedoch separate Status an denselben Commit senden.

GitHub-Prüfungen

Bei Pipelines, die mithilfe der Azure Pipelines-GitHub-App eingerichtet wurden, wird der Status in Form von GitHub-Prüfungen zurückgesendet. GitHub-Prüfungen ermöglichen das Senden detaillierter Informationen über Pipelinestatus und -test sowie Code Coverage und Fehler. Die GitHub-Prüfungen-API finden Sie hier.

Für jede Pipeline, die die GitHub-App verwendet, werden Prüfungen für die gesamte Ausführung und jeden Auftrag in dieser Ausführung zurückgesendet.

GitHub bietet drei Optionen, wenn bei einer oder mehreren Prüfausführungen für einen PR/Commit Fehler auftreten. Sie können die einzelne Prüfung erneut ausführen, alle fehlerhaften Prüfungen für diesen PR/Commit erneut ausführen oder alle Prüfungen erneut ausführen, unabhängig davon, ob sie ursprünglich erfolgreich waren oder nicht.

Wenn Sie neben dem Namen der Prüfausführung auf den Link „Erneut ausführen“ klicken, wiederholt Azure Pipelines die Ausführung, die die Prüfausführung generiert hat. Die resultierende Ausführung hat dieselbe Ausführungsnummer und verwendet dieselbe Version des Quellcodes, der Konfiguration und der YAML-Datei wie der ursprüngliche Build. Nur Aufträge, deren erste Ausführung nicht erfolgreich war, sowie alle abhängigen nachgelagerten Aufträge werden erneut ausgeführt. Wenn Sie auf den Link „Alle fehlerhaften Überprüfungen erneut ausführen“ klicken, hat dies die gleiche Auswirkung. Dies ist das gleiche Verhalten wie das Klicken auf „Ausführung wiederholen“ in der Azure Pipelines-Benutzeroberfläche. Wenn Sie auf „Alle Überprüfungen erneut ausführen“ klicken, wird eine neue Ausführung mit einer neuen Ausführungsnummer gestartet, und Änderungen in der Konfigurations- oder YAML-Datei werden aufgenommen.

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 GitHub-Integration lassen sich in die folgenden Kategorien einteilen:

• Verbindungstypen: Ich bin nicht sicher, welchen Verbindungstyp ich zum Verbinden meiner Pipeline mit GitHub verwende.
• Fehlende Trigger: Meine Pipeline wird nicht ausgelöst, wenn ich eine Aktualisierung in das Repository pushe.
• Fehler beim Auschecken: Meine Pipeline wird ausgelöst, aber im Check-Out-Schritt tritt ein Fehler auf.
• Falsche Version: Meine Pipeline wird ausgeführt, verwendet aber eine unerwartete Quell-/YAML-Version.
• Fehlende Statusaktualisierungen: Meine GitHub-PRs werden blockiert, da Azure Pipelines keine Statusaktualisierung gemeldet hat.

Verbindungstypen

Wie finde ich heraus, welchen GitHub-Verbindungstyp ich für meine Pipeline verwende, wenn ich Probleme mit Triggern beheben muss?

Die Problembehandlung bei Triggern hängt sehr stark vom Typ der GitHub-Verbindung ab, die Sie in Ihrer Pipeline verwenden. Es gibt zwei Möglichkeiten, den Verbindungstyp zu bestimmen: über GitHub und über Azure Pipelines.

• Über GitHub: Wenn ein Repository für die Verwendung der GitHub-App eingerichtet ist, lautet der Status für PRs und Commits „Prüfausführungen“. Wenn für das Repository Azure Pipelines mit OAuth- oder PAT-Verbindungen eingerichtet ist, liegen die Status im „alten“ Statusformat vor. Eine schnelle Möglichkeit, zu ermitteln, ob es sich beim Status um Prüfausführungen oder einfache Status handelt, besteht darin, die Registerkarte „Konversation“ zu einem GitHub-PR anzuzeigen.

  • Wenn der Link „Details“ zur Registerkarte „Überprüfungen“ umleitet, handelt es sich um eine Prüfausführung, und das Repository verwendet die App.
  • Wenn der Link „Details“ zur Azure DevOps-Pipeline umleitet, ist der Status ein Status im „alten Format“, und das Repository verwendet die App nicht.

• Über Azure Pipelines: Sie können den Verbindungstyp auch ermitteln, indem Sie sich die Pipeline in der Benutzeroberfläche von Azure Pipelines ansehen. Öffnen Sie den Editor für die Pipeline. Wählen Sie Trigger aus, um den klassischen Editor für die Pipeline zu öffnen. Wählen Sie dann die Registerkarte YAML und dort den Schritt Quellen abrufen aus. Es wird ein Banner Autorisiert über folgende Verbindung: angezeigt, in dem die Dienstverbindung angegeben ist, die zum Integrieren der Pipeline in GitHub verwendet wurde. Der Name der Dienstverbindung ist ein Link. Wählen Sie den Link aus, um zu den Eigenschaften der Dienstverbindung zu navigieren. In den Dienstverbindungseigenschaften ist der Typ der verwendeten Verbindung angegeben:

  • Azure Pipelines-App: GitHub-App-Verbindung
  • oauth: OAuth-Verbindung
  • personalaccesstoken: PAT-Authentifizierung

Wie ändere ich meine Pipeline so, dass statt OAuth die GitHub-App verwendet wird?

Die Verwendung einer GitHub-App anstelle einer OAuth- oder PAT-Verbindung ist die empfohlene Integration zwischen GitHub und Azure Pipelines. Führen Sie die folgenden Schritte aus, um zur GitHub-App zu wechseln:

1. Navigieren Sie hierher, und installieren Sie die App in der GitHub-Organisation Ihres Repositorys.
2. Während der Installation werden Sie zu Azure DevOps umgeleitet, um eine Azure DevOps-Organisation und ein entsprechendes Projekt auszuwählen. Wählen Sie die Organisation und das Projekt aus, die/das die klassische Buildpipeline enthält, für die Sie die App verwenden möchten. Diese Option ordnet die GitHub-App-Installation Ihrer Azure DevOps-Organisation zu. Wenn Sie Ihre Wahl ändern möchten, öffnen Sie diese Seite, um die GitHub-App aus Ihrer GitHub-Organisation zu deinstallieren und von vorne zu beginnen.
3. Auf der nächsten angezeigten Seite müssen Sie keine neue Pipeline erstellen.
4. Bearbeiten Sie Ihre Pipeline, indem Sie die Seite „Pipelines“ öffnen (z. B. https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), Ihre Pipeline auswählen und auf „Bearbeiten“ klicken.
5. Wenn es sich um eine YAML-Pipeline handelt, wählen Sie das Menü Trigger aus, um den klassischen Editor zu öffnen.
6. Wählen Sie den Schritt „Quellen abrufen“ in der Pipeline aus.
7. Wählen Sie auf der grünen Leiste mit dem Text „Autorisiert über folgende Verbindung:“ die Option „Ändern“ aus, und wählen Sie die GitHub-App-Verbindung mit demselben Namen wie die GitHub-Organisation aus, in der Sie die App installiert haben.
8. Wählen Sie auf der Symbolleiste „Speichern und in Warteschlange einreihen“ und dann erneut „Speichern und in Warteschlange einreihen“ aus. Wählen Sie den Link zu der Pipelineausführung aus, die in die Warteschlange eingereiht wurde, um sicherzustellen, dass sie erfolgreich ist.
9. Erstellen Sie einen Pull Request in Ihrem GitHub-Repository (oder schließen Sie einen Pull Request und öffnen ihn erneut), um sich zu vergewissern, dass ein Build erfolgreich im Abschnitt „Überprüfungen“ in die Warteschlange eingereiht wurde.

Warum wird kein GitHub-Repository angezeigt, das ich in Azure Pipelines auswählen kann?

Je nach Authentifizierungstyp und Besitz des Repositorys sind bestimmte Berechtigungen erforderlich.

• Wenn Sie die GitHub-App verwenden, finden Sie weitere Informationen unter GitHub-App-Authentifizierung.
• Wenn Sie OAuth verwenden, finden Sie weitere Informationen unter OAuth-Authentifizierung.
• Wenn Sie PATs verwenden, finden Sie weitere Informationen unter PAT-Authentifizierung (Personal Access Token).

Wenn ich während der Pipelineerstellung ein Repository auswähle, erhalte ich die Fehlermeldung, dass das Repository „{repo-name}“ mit der Azure Pipelines-GitHub-App in einer anderen Azure DevOps-Organisation verwendet wird.

Das bedeutet, dass Ihr Repository bereits einer Pipeline in einer anderen Organisation zugeordnet ist. CI- und PR-Ereignisse aus diesem Repository funktionieren nicht, da sie an die andere Organisation übermittelt werden. Führen Sie die folgenden Schritte aus, um die Zuordnung zur anderen Organisation zu entfernen, bevor Sie mit der Erstellung einer Pipeline fortfahren.

1. Öffnen Sie einen Pull Request in Ihrem GitHub-Repository, und fügen Sie den Kommentar /azp where ein. Damit wird eine Rückmeldung an die Azure DevOps-Organisation erstellt, der das Repository zugeordnet ist.

2. Um die Zuordnung zu ändern, deinstallieren Sie die App in der GitHub-Organisation, und installieren Sie sie erneut. Stellen Sie bei der Neuinstallation sicher, dass Sie die richtige Organisation auswählen, wenn Sie zu Azure DevOps umgeleitet werden.

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.

  

• Verwenden Sie die GitHub-App-Verbindung, um die Pipeline mit GitHub zu verbinden? Informationen dazu, wie Sie den vorhandenen Verbindungstyp bestimmen, finden Sie unter Verbindungstypen. Wenn Sie eine GitHub-App-Verbindung verwenden, führen Sie die folgenden Schritte aus:

  • Ist die Zuordnung zwischen GitHub und Azure DevOps ordnungsgemäß eingerichtet? Öffnen Sie einen Pull Request in Ihrem GitHub-Repository, und fügen Sie den Kommentar /azp where ein. Damit wird eine Rückmeldung an die Azure DevOps-Organisation erstellt, der das Repository zugeordnet ist.

    • Wenn keine Organisationen zum Erstellen dieses Repositorys mit der App eingerichtet sind, wechseln Sie zu https://github.com/<org_name>/<repo_name>/settings/installations, und schließen Sie die Konfiguration der App ab.

    • Wenn eine andere Azure DevOps-Organisation gemeldet wird, hat jemand bereits eine Pipeline für dieses Repository in einer anderen Organisation eingerichtet. Derzeit besteht die Einschränkung, dass ein GitHub-Repository nur einer einzigen DevOps-Organisation zugeordnet sein kann. Nur die Pipelines in der ersten Azure DevOps-Organisation können automatisch ausgelöst werden. Um die Zuordnung zu ändern, deinstallieren Sie die App in der GitHub-Organisation, und installieren Sie sie erneut. Stellen Sie bei der Neuinstallation sicher, dass Sie die richtige Organisation auswählen, wenn Sie zu Azure DevOps umgeleitet werden.

• Verwenden Sie OAuth oder PAT, um die Pipeline mit GitHub zu verbinden? Informationen dazu, wie Sie den vorhandenen Verbindungstyp bestimmen, finden Sie unter Verbindungstypen. Wenn Sie eine GitHub-Verbindung verwenden, führen Sie die folgenden Schritte aus:

  1. OAuth- und PAT-Verbindungen verwenden Webhooks, um Aktualisierungen an Azure Pipelines zu melden. Navigieren Sie in GitHub zu den Einstellungen für Ihr Repository und dann zu „Webhooks“. Vergewissern Sie sich, dass die Webhooks vorhanden sind. In der Regel sollten drei Webhooks angezeigt werden : „push“, „pull_request“ und „issue_comment“. Wenn dies nicht der Fall ist, müssen Sie die Dienstverbindung neu erstellen und die Pipeline aktualisieren, sodass die neue Dienstverbindung verwendet wird.

  2. Wählen Sie jeden der Webhooks in GitHub aus, und überprüfen Sie, ob die Payload, die dem Commit des Benutzers entspricht, vorhanden ist und erfolgreich an Azure DevOps gesendet wurde. Möglicherweise wird hier ein Fehler angezeigt, wenn das Ereignis nicht an Azure DevOps gemeldet werden konnte.

• Der Datenverkehr von Azure DevOps könnte von GitHub gedrosselt werden. 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 ein Repository sehr viele Aktualisierungen und Pull Requests enthält, kann bei diesem Aufruf aufgrund einer solchen Drosselung ein Fehler auftreten. Überprüfen Sie in diesem Fall, ob Sie die Häufigkeit von Builds reduzieren können, indem Sie die Batchverarbeitung oder striktere Pfad-/Branchfilter verwenden.

• 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.

Ich möchte nicht, dass Benutzer*innen die Liste der Branches für Trigger überschreiben, wenn sie die YAML-Datei aktualisieren. Was muss ich tun?

Benutzer*innen mit Berechtigungen zum Beitragen von Code können die YAML-Datei aktualisieren und zusätzliche Branches einschließen/ausschließen. Daher können Benutzer*innen ein eigenes Feature oder einen eigenen Benutzerbranch in ihre YAML-Datei aufnehmen und diese Aktualisierung an einen Feature- oder Benutzerbranch pushen. Das kann dazu führen, dass die Pipeline für alle Aktualisierungen in diesem Branch ausgelöst wird. Sie können dieses Verhalten wie folgt verhindern:

1. Bearbeiten Sie die Pipeline in der Azure Pipelines-Benutzeroberfläche.
2. Navigieren Sie zum Menü Trigger.
3. Wählen Sie YAML-Continuous Integration-Trigger von hier aus überschreiben aus.
4. Geben Sie die Branches an, die für den Trigger ein- oder ausgeschlossen werden sollen.

Wenn Sie diese Schritte ausführen, werden alle CI-Trigger ignoriert, die in der YAML-Datei angegeben sind.

Fehler beim Check-Out

Im Check-Out-Schritt wird der folgende Fehler in der Protokolldatei angezeigt. Wie behebe ich das Problem?

remote: Repository not found.
fatal: repository <repo> not found

Die Ursache könnte ein Ausfall von GitHub sein. Versuchen Sie, auf das Repository in GitHub zuzugreifen, und vergewissern Sie sich, dass der Zugriff funktioniert.

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 ausgewertet, die sich aus dem Mergen der Quell- und Zielbranches des Pull Requests ergibt, um festzustellen, ob ein PR-Build ausgeführt werden soll.

Fehlende Statusaktualisierungen

Mein PR in GitHub ist blockiert, weil Azure Pipelines den Status nicht aktualisiert hat.

Dies kann ein vorübergehender Fehler sein, der dazu führt, dass Azure DevOps nicht mit GitHub kommunizieren kann. Wiederholen Sie den Check-In-Vorgang in GitHub, wenn Sie die GitHub-App verwenden. Andernfalls nehmen Sie eine unwichtige Aktualisierung im PR vor, um festzustellen, ob das Problem behoben werden kann.

Verwandte Artikel

• Geplante Trigger
• Pipelineabschlusstrigger