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:

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.

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.

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.

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

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.

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:

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.

trigger:
- main
- releases/*

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

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

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

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

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

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

# A pipeline with no CI trigger
trigger: none

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

pr:
- main
- releases/*

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

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

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

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

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

# no PR triggers
pr: none

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.

   

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

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.

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:

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.

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

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

Submodule

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

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.

Synchronisieren von Tags

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.

steps:
- checkout: self
  fetchTags: true

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.

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.

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

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.

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

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

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.

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

git clean -ffdx
git reset --hard HEAD

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

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.

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