Erstellen von GitHub-Repositorys

Azure DevOps Services-

Azure-Pipelines können automatisch jede Pullanforderung erstellen und überprüfen und an Ihr GitHub-Repository übernehmen. In diesem Artikel wird beschrieben, wie Sie die Integration zwischen GitHub und Azure Pipelines konfigurieren.

Wenn Sie mit der Integration von Pipelines mit GitHub noch nicht vertraut sind, führen Sie die Schritte in Erstellen Ihrer ersten Pipelineaus. Kehren Sie zu diesem Artikel zurück, um mehr über das Konfigurieren und Anpassen der Integration zwischen GitHub und Azure Pipelines zu erfahren.

Organisationen und Benutzer

GitHub- und Azure-Pipelines sind zwei unabhängige Dienste, die sich gut zusammen integrieren. Jeder von ihnen verfügt über eine eigene Organisation und Benutzerverwaltung. In diesem Abschnitt wird empfohlen, wie Die Organisation und Benutzer von GitHub in Azure Pipelines repliziert werden.

Organisationen

Die Struktur von GitHub besteht aus Organisationen und Benutzerkonten, die Repositorysenthalten. Siehe GitHub-Dokumentation.

Die Struktur von Azure DevOps besteht aus Organisationen, die Projekteenthalten. Siehe Planen der Organisationsstruktur.

Azure DevOps kann Ihre GitHub-Struktur widerspiegeln mit:

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

So richten Sie eine identische Struktur in Azure DevOps ein:

1. Erstellen Sie eine DevOps-Organisation, die nach Ihrer GitHub-Organisation oder Ihrem Benutzerkonto benannt ist. Sie enthält eine URL wie https://dev.azure.com/your-organization.
2. Erstellen Sie in der DevOps-Organisation Projekte, die nach Ihren Repositorys benannt sind. Sie verfügen über URLs wie https://dev.azure.com/your-organization/your-repository.
3. Erstellen Sie im DevOps-Projekt Pipelines, die nach der GitHub-Organisation benannt sind, und erstellen Sie Repositorys, die sie erstellen, z. B. your-organization.your-repository. Dann ist klar, für welche Repositorys sie sich gerade befinden.

Nach diesem Muster verfügen Ihre GitHub-Repositorys und Azure DevOps-Projekte über übereinstimmende URL-Pfade. Zum Beispiel:

Benutzer

Ihre GitHub-Benutzer erhalten keinen automatischen Zugriff auf Azure-Pipelines. Azure-Pipelines wissen nicht von GitHub-Identitäten. Aus diesem Grund gibt es keine Möglichkeit, Azure Pipelines so zu konfigurieren, dass Benutzer automatisch über einen Buildfehler oder einen PR-Überprüfungsfehler mit ihrer GitHub-Identität und E-Mail-Adresse benachrichtigt werden. Sie müssen explizit neue Benutzer in Azure Pipelines erstellen, um GitHub-Benutzer zu replizieren. Nachdem Sie neue Benutzer erstellt haben, können Sie ihre Berechtigungen in Azure DevOps so konfigurieren, dass sie ihre Berechtigungen in GitHub widerspiegeln. Sie können Benachrichtigungen in DevOps auch mithilfe ihrer DevOps-Identität konfigurieren.

GitHub-Organisationsrollen

GitHub-Organisationsmitgliedsrollen finden Sie unter https://github.com/orgs/your-organization/people (ersetzen your-organization).

DevOps-Organisationsmitgliedsberechtigungen finden Sie unter https://dev.azure.com/your-organization/_settings/security (ersetzen your-organization).

Rollen in einer GitHub-Organisation und gleichwertige Rollen in einer Azure DevOps-Organisation werden unten angezeigt.

GitHub-Benutzerkontorollen

Ein GitHub-Benutzerkonto hat eine Rolle, die besitzer des Kontos ist.

DevOps-Organisationsmitgliedsberechtigungen finden Sie unter https://dev.azure.com/your-organization/_settings/security (ersetzen your-organization).

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

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

Gleichwertige Berechtigungen zwischen GitHub-Repositorys und Azure DevOps-Projekten sind wie folgt.

Wenn Ihr GitHub-Repository Teams die Berechtigung erteilt, können Sie im Abschnitt Teams Ihrer Azure DevOps-Projekteinstellungen übereinstimmende Teams erstellen. Fügen Sie dann die Teams wie Benutzer zu den oben genannten Sicherheitsgruppen hinzu.

Pipelinespezifische Berechtigungen

Führen Sie die folgenden Schritte aus, um Benutzern oder Teams Berechtigungen für bestimmte Pipelines in einem DevOps-Projekt zu erteilen:

1. Besuchen Sie die Pipelines-Seite 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ü..." Sicherheits-aus.
4. Wählen Sie Hinzufügen aus..., einen bestimmten Benutzer, ein bestimmtes Team oder eine bestimmte Gruppe hinzuzufügen und seine Berechtigungen für die Pipeline anzupassen.

Zugriff auf GitHub-Repositorys

Azure-Pipelines müssen Zugriff auf Ihre Repositorys erhalten, um deren Builds auszulösen und den Code während der Builds abzurufen.

Es gibt drei Authentifizierungstypen zum Gewähren des Zugriffs auf Ihre GitHub-Repositorys bei der Erstellung einer Pipeline.

GitHub-App-Authentifizierung

Die GitHub-App für Azure Pipelines ist die empfohlenen Authentifizierungstyps für fortlaufende Integrationspipelines. Nachdem Sie die GitHub-App in Ihrem GitHub-Konto oder Ihrer Organisation installiert haben, wird Ihre Pipeline ohne Ihre persönliche GitHub-Identität ausgeführt. Builds und GitHub-Statusupdates werden mithilfe der Azure Pipelines-Identität ausgeführt. Die App funktioniert mit GitHub Checks zum Anzeigen von Build-, Test- und Codeabdeckungsergebnissen in GitHub.

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

Nach der Installation wird die GitHub-App zur Standardauthentifizierungsmethode von Azure Pipelines zu 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 Gedanken über Azure Pipelines machen, die Massen-E-Mails senden oder Pipelines in Ihrem Auftrag automatisch einrichten. Wenn die App jedoch für alle Repositorys installiert ist, hat das von der Anwendung verwendete Token Zugriff auf alle Repositorys, einschließlich privater Repositorys. Aus Sicherheitsgründen wird empfohlen, private und öffentliche Repositorys auf Organisationsebene zu trennen. Dies bedeutet, dass eine dedizierte Organisation nur für öffentliche Projekte ohne private Repositorys vorhanden ist. Wenn aus irgendeinem Grund öffentliche und private Repositorys in derselben Organisation vorhanden sein müssen, anstatt den Zugriff für alle Repositorys zu verwenden, wählen Sie explizit die Repositorys aus, auf die die Anwendung Zugriff haben soll. Dies erfordert mehr Arbeit für Administratoren, stellt jedoch eine bessere Sicherheitsverwaltung sicher.

Erforderliche Berechtigungen in GitHub

Die Installation der GitHub-App von Azure Pipelines erfordert, dass Sie Ein GitHub-Organisationsbesitzer oder Repositoryadministrator sein müssen. Darüber hinaus müssen Sie zum Erstellen einer Pipeline für ein GitHub-Repository mit kontinuierlichen Integrations- und Pullanforderungstriggern die erforderlichen GitHub-Berechtigungen konfiguriert haben. Andernfalls wird das Repository beim Erstellen einer Pipeline 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 GitHub-App von Azure Pipelines in Ihrem persönlichen GitHub-Konto, und Sie können dieses Repository beim Erstellen der Pipeline in Azure Pipelines auflisten.

• Wenn sich das Repository im persönlichen GitHub-Konto einer anderen Person befindet, muss die andere Person die Azure Pipelines GitHub-App in ihrem persönlichen GitHub-Konto installieren. Sie müssen als Mitarbeiter in den Einstellungen des Repositorys unter "Mitarbeiter" hinzugefügt werden. Akzeptieren Sie die Einladung, einen Mitarbeiter zu sein, indem Sie den Link verwenden, 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 befindet, die Sie besitzen, installieren Sie die GitHub-App von Azure Pipelines in der GitHub-Organisation. Sie müssen auch als Mitarbeiter 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 befindet, die eine andere Person besitzt, muss ein GitHub-Organisationsbesitzer oder Repositoryadministrator die GitHub-App von Azure Pipelines in der Organisation installieren. Sie müssen als Mitarbeiter hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter "Mitarbeiter und Teams" hinzugefügt werden. Akzeptieren Sie die Einladung, einen Mitarbeiter zu sein, indem Sie den Link verwenden, 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 an, z. B.:

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

Dies bedeutet, dass die GitHub-App wahrscheinlich bereits für Ihre Organisation 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 Pullanforderungen 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-Statusupdates werden im Namen Ihrer persönlichen GitHub-Identität ausgeführt. Damit Pipelines weiterhin funktionieren, muss ihr Repositoryzugriff aktiv bleiben. Einige GitHub-Features, z. B. "Checks", sind mit OAuth nicht verfügbar und erfordern die GitHub-App.

Um OAuth zu verwenden, wählen Sie Wählen Sie eine andere Verbindung unter der Liste der Repositorys aus, während Sie eine Pipeline erstellen. Wählen Sie dann Autorisieren aus, um sich bei GitHub anzumelden und mit OAuth zu autorisieren. Eine OAuth-Verbindung wird in Ihrem Azure DevOps-Projekt zur späteren Verwendung gespeichert und in der Pipeline verwendet, die erstellt wird.

Erforderliche Berechtigungen in GitHub

Um eine Pipeline für ein GitHub-Repository mit fortlaufender Integration und Pullanforderungstriggern zu erstellen, müssen Sie die erforderlichen GitHub-Berechtigungen konfiguriert haben. Andernfalls wird das Repository beim Erstellen einer Pipeline 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 bei GitHub mit OAuth mit Ihren persönlichen GitHub-Kontoanmeldeinformationen. Dies kann in den Azure DevOps-Projekteinstellungen unter Pipelines > Dienstverbindungen > Neue Dienstverbindung > GitHub > Autorisieren erfolgen. Gewähren Sie Azure Pipelines Zugriff auf Ihre Repositorys unter "Berechtigungen" hier.

• Wenn sich das Repository im persönlichen GitHub-Konto einer anderen Person befindet, muss sich die andere Person mit 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 Zugriff auf ihre Repositorys unter "Berechtigungen" gewähren, hier. Sie müssen als Mitarbeiter in den Einstellungen des Repositorys unter "Mitarbeiter" hinzugefügt werden. Akzeptieren Sie die Einladung, einen Mitarbeiter zu sein, indem Sie den Link verwenden, der Ihnen per E-Mail gesendet wird.

• Wenn sich das Repository in einer GitHub-Organisation befindet, die Sie besitzen , mindestens einmal, authentifizieren Sie sich bei GitHub mit OAuth mit Ihren persönlichen GitHub-Kontoanmeldeinformationen. Dies kann in den Azure DevOps-Projekteinstellungen unter Pipelines > Dienstverbindungen > Neue Dienstverbindung > GitHub > Autorisieren erfolgen. Gewähren Sie Azure Pipelines Zugriff auf Ihre Organisation unter "Organisationszugriff" hier. Sie müssen als Mitarbeiter 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 befindet, die eine andere Person besitzt, muss sich mindestens einmal ein GitHub-Organisationsbesitzer bei GitHub mit OAuth mit ihren persönlichen GitHub-Kontoanmeldeinformationen authentifizieren. Dies kann in den Azure DevOps-Projekteinstellungen unter Pipelines > Dienstverbindungen > Neue Dienstverbindung > GitHub > Autorisieren erfolgen. Der Organisationsbesitzer muss Azure Pipelines Zugriff auf die Organisation unter "Organisationszugriff" gewähren, hier. Sie müssen als Mitarbeiter hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter "Mitarbeiter und Teams" hinzugefügt werden. Akzeptieren Sie die Einladung, einen Mitarbeiter zu sein, indem Sie den Link verwenden, der Ihnen per E-Mail gesendet wird.

OAuth-Zugriff widerrufen

Nachdem Sie Azure Pipelines für die Verwendung von OAuth autorisiert haben, um sie später zu widerrufen und die weitere Verwendung zu verhindern, besuchen Sie OAuth-Apps in Ihren GitHub-Einstellungen. Sie können es auch aus der Liste der GitHub-Dienstverbindungen in Ihren Azure DevOps-Projekteinstellungen löschen.

Authentifizierung des persönlichen Zugriffstokens (PAT)

PATs sind effektiv identisch mit OAuth, aber Sie können steuern, welche Berechtigungen Azure Pipelines erteilt werden. Builds und GitHub-Statusupdates werden im Namen Ihrer persönlichen GitHub-Identität ausgeführt. Damit Builds weiterhin funktionieren, muss ihr Repositoryzugriff aktiv bleiben.

Um einen PAT zu erstellen, besuchen Sie persönliche Zugriffstoken in Ihren GitHub-Einstellungen. Die erforderlichen Berechtigungen sind repo, admin:repo_hook, read:userund user:email. Dies sind die gleichen Berechtigungen, die bei verwendung von OAuth oben erforderlich sind. Kopieren Sie den generierten PAT in die Zwischenablage, und fügen Sie ihn in eine neue GitHub-Dienstverbindung in Ihren Azure DevOps-Projekteinstellungen ein. Nennen Sie für zukünftige Rückrufe die Dienstverbindung nach Ihrem GitHub-Benutzernamen. Sie steht in Ihrem Azure DevOps-Projekt zur späteren Verwendung beim Erstellen von Pipelines zur Verfügung.

Erforderliche Berechtigungen in GitHub

Um eine Pipeline für ein GitHub-Repository mit fortlaufender Integration und Pullanforderungstriggern zu erstellen, müssen Sie die erforderlichen GitHub-Berechtigungen konfiguriert haben. Andernfalls wird das Repository beim Erstellen einer Pipeline 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 der PAT über die erforderlichen Zugriffsbereiche unter persönliche Zugriffstoken: repo, admin:repo_hook, read:userund user:emailverfügen.

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

• Wenn sich das Repository in einer GitHub-Organisation befindet, die Sie besitzen, muss der PAT über die erforderlichen Zugriffsbereiche unter persönliche Zugriffstokenverfügen: repo, admin:repo_hook, read:userund user:email. Sie müssen als Mitarbeiter 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 befindet, die eine andere Person besitzt, muss der PAT über die erforderlichen Zugriffsbereiche unter Persönliche Zugriffstoken: repo, admin:repo_hook, read:userund user:emailverfügen. Sie müssen als Mitarbeiter hinzugefügt werden, oder Ihr Team muss in den Einstellungen des Repositorys unter "Mitarbeiter und Teams" hinzugefügt werden. Akzeptieren Sie die Einladung, einen Mitarbeiter zu sein, indem Sie den Link verwenden, der Ihnen per E-Mail gesendet wird.

Widerrufen des PAT-Zugriffs

Nachdem Sie Azure Pipelines für die Verwendung eines PAT autorisiert haben, um es später zu löschen und weitere Verwendung zu verhindern, besuchen Sie persönliche Zugriffstoken in Ihren GitHub-Einstellungen. Sie können es auch aus der Liste der GitHub-Dienstverbindungen in Ihren Azure DevOps-Projekteinstellungen löschen.

CI-Trigger

Fortlaufende Integrationstrigger führen dazu, dass eine Pipeline ausgeführt wird, wenn Sie ein Update an die angegebenen Verzweigungen senden oder 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 würde. Fügen Sie einfach [skip ci] in die Nachricht oder Beschreibung eines der Commits ein, die Teil eines Pushs sind, und Azure Pipelines überspringen die Ausführung von CI für diesen Push. Sie können auch eine der folgenden Variationen 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, unterschiedliche Schritte, Aufträge oder Phasen in Ihrer Pipeline auszuführen, je nachdem, welche Art von Trigger die Ausführung gestartet hat. Dazu können Sie die Systemvariable Build.Reasonverwenden. Fügen Sie z. B. die folgende Bedingung zu Ihrem Schritt, Ihrem Auftrag oder ihrer Phase hinzu, um sie von PR-Überprüfungen auszuschließen.

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

Verhalten von Triggern beim Erstellen neuer Verzweigungen

Es ist üblich, mehrere Pipelines für dasselbe Repository zu konfigurieren. Beispielsweise haben Sie möglicherweise eine Pipeline, um die Dokumente für Ihre App und eine andere zu erstellen, um den Quellcode zu erstellen. Sie können CI-Trigger mit entsprechenden Verzweigungsfiltern und Pfadfiltern in jeder dieser Pipelines konfigurieren. Sie möchten beispielsweise, dass eine Pipeline ausgelöst wird, wenn Sie eine Aktualisierung an den docs Ordner senden, und eine weitere, die ausgelöst werden soll, wenn Sie eine Aktualisierung an Den Anwendungscode senden. In diesen Fällen müssen Sie verstehen, wie die Pipelines ausgelöst werden, wenn eine neue Verzweigung erstellt wird.

Dies ist das Verhalten, wenn Sie eine neue Verzweigung (die den Verzweigungsfiltern entspricht) an Ihr Repository übertragen:

• Wenn Ihre Pipeline Pfadfilter enthält, wird sie nur ausgelöst, wenn die neue Verzweigung Änderungen an Dateien aufweist, die diesem Pfadfilter entsprechen.
• Wenn Ihre Pipeline keine Pfadfilter enthält, wird sie ausgelöst, auch wenn keine Änderungen in der neuen Verzweigung vorhanden sind.

Wildcards

Wenn Sie eine Verzweigung, ein Tag oder einen Pfad angeben, können Sie einen genauen Namen oder einen Wildcardnamen verwenden. Mit Wildcards-Mustern können * null oder mehr Zeichen abgleichen und ? einem einzelnen Zeichen entsprechen.

• Wenn Sie ihr Muster mit * in einer YAML-Pipeline beginnen, müssen Sie das Muster in Anführungszeichen umschließen, z. B. "*-releases".
• Für Verzweigungen und Tags:
  • Ein Wildcard kann an einer beliebigen Stelle im Muster angezeigt werden.
• Für Pfade:
  • In Azure DevOps Server 2022 und höher, einschließlich Azure DevOps Services, kann ein Wildcard überall innerhalb eines Pfadmusters angezeigt werden, und Sie können * oder ?verwenden.
  • In Azure DevOps Server 2020 und niedriger können Sie * als endgültiges Zeichen einschließen, aber es macht nichts anderes als die Angabe des Verzeichnisnamens selbst. Sie können nicht* in der 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-Anforderungstrigger führen dazu, dass eine Pipeline ausgeführt wird, wenn eine Pullanforderung mit einer der angegebenen Zielverzweigungen geöffnet wird oder wenn Aktualisierungen an einer solchen Pullanforderung vorgenommen werden.

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 über eine offene PR verfügen und Änderungen an den Quellzweig übertragen, können mehrere Pipelines ausgeführt werden:

• Die Pipelines, die über einen PR-Trigger für die ZIEL-Verzweigung der PR verfügen, werden auf dem Zusammenführung commit (der zusammengeführte Code zwischen der Quell- und Zielzweige der Pullanforderung) ausgeführt, unabhängig davon, ob pushed Commits vorhanden sind, deren Nachrichten oder Beschreibungen [skip ci] (oder eine seiner Varianten) enthalten.
• Die Pipelines, die durch Änderungen an der QUELL-Verzweigung der PR ausgelöst werden, wenn keine pushed Commits vorhanden sind, deren Nachrichten oder Beschreibungen [skip ci] (oder eine der Varianten) enthalten. Wenn mindestens ein pushed Commit [skip ci]enthält, werden die Pipelines nicht ausgeführt.

Nachdem Sie die PR zusammengeführt haben, führt Azure Pipelines die CI-Pipelines aus, die durch Pushs an die Ziel-Verzweigung ausgelöst werden, wenn die Nachricht oder Beschreibung des Seriendrucks keine [skip ci] (oder eine seiner Varianten) enthält.

Geschützte Verzweigungen

Sie können einen Überprüfungsbuild mit jeder Commit- oder Pullanforderung ausführen, die auf eine Verzweigung ausgerichtet ist, und sogar das Zusammenführen von Pullanforderungen verhindern, bis ein Überprüfungsbuild erfolgreich ist.

Um obligatorische Validierungsbuilds für ein GitHub-Repository zu konfigurieren, müssen Sie besitzer sein, ein Mitarbeiter mit der Administratorrolle oder ein GitHub-Organisationsmitglied mit der Rolle "Schreiben".

1. Erstellen Sie zunächst eine Pipeline für das Repository, und erstellen Sie sie mindestens einmal, damit ihr Status auf GitHub gepostet wird, wodurch GitHub den Namen der Pipeline bekannt macht.

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

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

   

Beiträge aus externen Quellen

Wenn Ihr GitHub-Repository Open Source ist, können Sie Ihr Azure DevOps-Projekt öffentlich machen, damit jeder die Buildergebnisse, Protokolle und Testergebnisse Ihrer Pipeline anzeigen kann, ohne sich anzumelden. Wenn Benutzer außerhalb Ihrer Organisation Ihr Repository verzweigen und Pullanforderungen übermitteln, können sie den Status von Builds anzeigen, die diese Pullanforderungen automatisch überprüfen.

Beachten Sie bei der Verwendung von Azure-Pipelines in einem öffentlichen Projekt beim Akzeptieren von Beiträgen aus externen Quellen die folgenden Überlegungen.

• Zugriffsbeschränkungen
• Überprüfen von Beiträgen von Forks
• Wichtige Sicherheitsaspekte

Zugriffsbeschränkungen

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

• Geheimnisse: Standardmäßig werden geheime Schlüssel, die Ihrer Pipeline zugeordnet sind, nicht zum Abrufen von Anforderungsüberprüfungen von Forks zur Verfügung gestellt. Siehe Überprüfen von Beiträgen von 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 und nicht in anderen Projekten der Azure DevOps-Organisation auf Ressourcen wie Buildartefakte oder Testergebnisse zugreifen.
• Azure Artifacts-Pakete: Wenn Ihre Pipelines Zugriff auf Pakete von Azure Artifacts benötigen, müssen Sie explizit die Berechtigung für das Project Build Service Konto erteilen, um auf die Paketfeeds zuzugreifen.

Beiträge von Forks

Wenn Sie eine Pipeline erstellen, wird sie automatisch für Pullanforderungen von Verlangeln Ihres Repositorys ausgelöst. Sie können dieses Verhalten ändern, sorgfältig überlegen, 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 Pipelinesaus, suchen Sie Ihre Pipeline, und wählen Sie Bearbeitenaus.
2. Wählen Sie die Registerkarte Triggers aus. Nachdem Sie den Pullanforderungstriggeraktiviert oder deaktiviert haben, aktivieren oder deaktivieren Sie das Kontrollkästchen Build pull requests from forks of this repository.

Standardmäßig werden mit GitHub-Pipelines geheime Schlüssel, die Ihrer Buildpipeline zugeordnet sind, nicht für Pull-Anforderungsbuilds von Forks verfügbar gemacht. Diese geheimen Schlüssel sind standardmäßig mit GitHub Enterprise Server-Pipelines aktiviert. Geheime Schlüssel sind:

• Ein Sicherheitstoken mit Zugriff auf Ihr GitHub-Repository.
• Diese Elemente, wenn Ihre Pipeline sie verwendet:
  • Dienstverbindung Anmeldeinformationen
  • Dateien aus der sicheren Dateienbibliothek
  • Erstellen Variablengeheimen

Um diese Vorsichtsmaßnahme für GitHub-Pipelines zu umgehen, aktivieren Sie das Kontrollkästchen "Geheime Schlüssel für Builds von Freigängen verfügbar machen. Beachten Sie die Auswirkungen dieser Einstellung auf die Sicherheit.

Weitere Informationen finden Sie unter Repositoryschutz – Forks.

Sie können zentral definieren, wie Pipelines PRs aus verzweigten GitHub-Repositorys erstellen, indem Sie die Limit building pull requests from forked GitHub repositorys control. Sie ist auf Organisation und Projektebene verfügbar. Sie können folgendes auswählen:

• Deaktivieren des Erstellens von Pullanforderungen aus Verzweigungsrepositorys
• Sicheres Erstellen von Pullanforderungen aus Verzweigungsrepositorys
• Anpassen von Regeln zum Erstellen von Pullanforderungen aus Verzweigungsrepositorys

Ab Sprint 229, um die Sicherheit Ihrer Pipelines zu verbessern, erstellt Azure Pipelines keine Pullanforderungen mehr aus verzweigten GitHub-Repositorys. Für neue Projekte und Organisationen ist der Standardwert der Limit building pull requests from forked GitHub repositorys setting is Disable building pull requests from forked repositories.

Wenn Sie die Securely Build Pull-Anforderungen aus Verzweigungsrepositorys Option auswählen, können alle Pipelines, Organisations- oder projektweiten Pipelines, Organisations- oder projektweiten, keine geheimen Schlüssel für Builds von PRs aus Verzweigungsrepositorys zur Verfügung stellen, diese Builds nicht über die gleichen Berechtigungen wie normale Builds verfügen können, und von einem PR-Kommentar ausgelöst werden müssen. Projekte können sich weiterhin entscheiden, nicht pipelines das Erstellen solcher PRs erlauben.

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 eine PR aus einem verzweigten GitHub-Repository zu erstellen, wenn die PR zu Nicht-Teammitgliedern und Nichtmitwirkenden gehört. Sie können es ihnen jedoch ermöglichen, geheime Schlüssel für solche Builds zur Verfügung zu stellen. Projekte können sich entscheiden, keine Pipelines das Erstellen solcher PRs oder die sichere Erstellung von Pipelines zu oder noch restriktivere Einstellungen als auf Organisationsebene festgelegt haben.

Die Steuerung ist für vorhandene Organisationen deaktiviert. Ab September 2023 haben neue Organisationen Sichere Erstellung von Pullanforderungen aus verzweigten Repositorys standardmäßigaktiviert.

Wichtige Sicherheitsaspekte

Ein GitHub-Benutzer kann Ihr Repository verzweigen, ändern und eine Pull-Anforderung erstellen, um Änderungen an Ihrem Repository vorzuschlagen. Diese Pullanforderung kann schädlichen Code enthalten, der als Teil Ihres ausgelösten Builds ausgeführt werden soll. Ein solcher Code kann auf folgende Weise Schaden verursachen:

• Verlecken Sie geheime Schlüssel aus Ihrer Pipeline. Um dieses Risiko zu minimieren, aktivieren Sie nicht das Kontrollkästchen Geheime Schlüssel für Builds von Forks verfügbar machen, Kontrollkästchen, wenn Ihr Repository öffentlich oder nicht vertrauenswürdige Benutzer Pullanforderungen senden können, die automatisch Builds auslösen. Diese Option ist standardmäßig deaktiviert.

• Kompromittieren Sie den Computer, auf dem der Agent ausgeführt wird, um Code oder geheime Schlüssel aus anderen Pipelines zu stehlen. Gehen Sie wie folgt vor, um dies zu vermeiden:

  • Verwenden Sie einen von Microsoft gehosteten Agentpool, um Pullanforderungen von Forks zu erstellen. Von Microsoft gehostete Agent-Computer werden sofort gelöscht, nachdem sie einen Build abgeschlossen haben, sodass es keine dauerhaften Auswirkungen gibt, wenn sie kompromittiert werden.

  • Wenn Sie einen selbst gehosteten Agentverwenden müssen, speichern Sie keine geheimen Schlüssel, oder führen Sie andere Builds und Versionen aus, die geheime Schlüssel für denselben Agent verwenden, es sei denn, Ihr Repository ist privat und Sie vertrauen Pullanforderungserstellern.

Kommentartrigger

Repositorymitarbeiter können eine Pullanforderung kommentieren, um eine Pipeline manuell auszuführen. Im Folgenden finden Sie einige häufige Gründe dafür, warum Sie dies tun sollten:

• Möglicherweise möchten Sie keine Pullanforderungen von unbekannten Benutzern automatisch erstellen, bis ihre Änderungen überprüft werden können. Sie möchten, dass eines Ihrer Teammitglieder zuerst den Code überprüft und dann die Pipeline ausführt. Dies wird häufig als Sicherheitsmaßnahme beim Erstellen von Code aus Verzweigungsrepositorys verwendet.
• Möglicherweise möchten Sie eine optionale Testsuite oder einen weiteren Validierungsbuild ausführen.

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

1. Aktivieren Sie Pullanforderungstrigger für Ihre Pipeline, und stellen Sie sicher, dass Sie die Ziel-Verzweigung nicht ausgeschlossen haben.
2. Bearbeiten Sie im Azure Pipelines-Webportal Ihre Pipeline, und wählen Sie Weitere Aktionen, Triggeraus. Aktivieren Sie dann unter Pull-AnforderungsüberprüfungVor dem Erstellen einer Pullanforderungden Kommentar eines Teammitglieds anfordern.
   • Wählen Sie Bei allen Pullanforderungen, dass der Kommentar eines Teammitglieds vor dem Erstellen einer Pullanforderung erforderlich ist. Mit diesem Workflow überprüft ein Teammitglied die Pullanforderung und löst den Build mit einem Kommentar aus, sobald die Pullanforderung als sicher eingestuft wurde.
   • Wählen Sie Nur bei Pullanforderungen von Nicht-Teammitgliedern aus,, dass der Kommentar eines Teammitglieds nur dann erforderlich ist, wenn eine PR von einem Nicht-Teammitglied erstellt wird. In diesem Workflow benötigt ein Teammitglied keine Überprüfung eines sekundären Teammitglieds, um einen Build auszulösen.

Bei diesen beiden Änderungen wird der Build der Pullanforderungsüberprüfung nicht automatisch ausgelöst, es sei denn, Nur bei Pullanforderungen von Nicht-Teammitgliedern ausgewählt wird und die PR von einem Teammitglied vorgenommen wird. Nur Repositorybesitzer und Mitarbeiter mit der Berechtigung "Schreiben" können den Build auslösen, indem er die Pullanforderung mit /AzurePipelines run oder /AzurePipelines run <pipeline-name>kommentiert.

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

Behandeln von Problemen mit Pullanforderungskommentartriggern

Wenn Sie über die erforderlichen Repositoryberechtigungen verfügen, pipelines jedoch nicht von Ihren Kommentaren ausgelöst werden, stellen Sie sicher, dass Ihre Mitgliedschaft öffentlichen in der Organisation des Repositorys ist, oder fügen Sie sich direkt als Repositorymitarbeiter hinzu. Pipelines können keine Mitglieder der privaten Organisation sehen, es sei denn, sie sind direkte Mitarbeiter oder gehören zu einem Team, das ein direkter Mitarbeiter ist. Sie können Ihre GitHub-Organisationsmitgliedschaft von privat in öffentlich hier ändern (ersetzen Sie Your-Organization durch den Namen Ihrer Organisation): https://github.com/orgs/Your-Organization/people.

Informationsläufe

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 pushed commit. Es geschieht auch als Reaktion auf interne Trigger, z. B. um zu überprüfen, ob Codeänderungen vorhanden sind und eine geplante Ausführung starten oder nicht. Der Quellcodeabruf kann aus mehreren Gründen fehlschlagen, wobei häufig eine Einschränkung durch den Git-Repositoryanbieter angefordert wird. Das Vorhandensein einer Informationsausführung bedeutet nicht unbedingt, dass Azure DevOps die Pipeline ausführen würde.

Eine Informationsausführung sieht im folgenden Screenshot aus.

Sie können eine Informationsausführung anhand der folgenden Attribute erkennen:

• Status ist Canceled
• Die Dauer ist < 1s
• Der Name des Ausführens 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 in der Regel den BitBucket/GitHub-Fehler, der dazu führte, dass die YAML-Pipelinelast fehlschlug.
• Keine Phasen / Aufträge / Schritte

Erfahren Sie mehr über Informationsläufe.

Kasse

Wenn eine Pipeline ausgelöst wird, ruft Azure Pipelines Ihren Quellcode aus dem Azure Repos Git-Repository ab. Sie können verschiedene Aspekte der Vorgehensweise steuern.

Bevorzugte Version von Git

Der Windows-Agent verfügt über eine eigene Kopie von Git. Wenn Sie lieber Ihre eigene Git bereitstellen möchten, anstatt die enthaltene Kopie zu verwenden, legen Sie System.PreferGitFromPath auf truefest. Diese Einstellung gilt immer für Nicht-Windows-Agents.

Auscheckpfad

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

Untermodule

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-Untermodule aus, solange sie:

• Nicht authentifiziert: Ein öffentliches, nicht authentifiziertes Repository ohne Anmeldeinformationen, die zum Klonen oder Abrufen erforderlich sind.

• authentifiziert:

  • Im selben Projekt wie das oben angegebene Azure Repos Git-Repository enthalten. Die gleichen Anmeldeinformationen, die vom Agent zum Abrufen der Quellen aus dem Hauptrespository verwendet werden, werden auch zum Abrufen der Quellen für Untermodule verwendet.

  • Wird mithilfe einer URL relativ zum Haupt-Repository hinzugefügt. Zum Beispiel

    • Dies wäre ausgecheckt: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      In diesem Beispiel bezieht sich das Untermodul auf ein Repository (FabrikamFiber) in derselben Azure DevOps-Organisation, aber in einem anderen Projekt (FabrikamFiberProject). Die gleichen Anmeldeinformationen, die vom Agent zum Abrufen der Quellen aus dem Hauptrespository verwendet werden, werden auch zum Abrufen der Quellen für Untermodule verwendet. Dies erfordert, dass das Auftragszugriffstoken Zugriff auf das Repository im zweiten Projekt hat. Wenn Sie das Auftragszugriffstoken wie im obigen Abschnitt erläutert eingeschränkt haben, können Sie dies nicht tun. Sie können zulassen, dass das Auftragszugriffstoken auf das Repository im zweiten Projekt zugreifen kann, indem Sie entweder (a) explizit zugriff auf das Projektbuilddienstkonto im zweiten Projekt gewähren oder (b) anstelle von Token mit Projektbereich für die gesamte Organisation sammlungsbezogene Zugriffstoken verwenden. Weitere Informationen zu diesen Optionen und deren Sicherheitsauswirkungen finden Sie unter Access-Repositorys, Artefakte und andere Ressourcen.

    • Dies wäre nicht ausgecheckt: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternative zur Verwendung der Option "Untermodule auschecken"

In einigen Fällen können Sie die Option Auschecken nicht verwenden. Möglicherweise gibt es ein Szenario, in dem für den Zugriff auf die Untermodule eine andere Gruppe von Anmeldeinformationen erforderlich ist. Dies kann z. B. passieren, wenn Ihr Hauptrepository und Ihre Untermodule-Repositorys nicht in derselben Azure DevOps-Organisation gespeichert sind oder wenn Ihr Auftragszugriffstoken keinen Zugriff auf das Repository in einem anderen Projekt hat.

Wenn Sie die Option Auschecken von Untermodulen nicht verwenden können, können Sie stattdessen einen benutzerdefinierten Skriptschritt verwenden, um Untermodule abzurufen. Rufen Sie zunächst ein persönliches Zugriffstoken (PAT) ab und stellen Sie ihr pat:voran. Als Nächstes base64-codierte dieser präfixierten Zeichenfolge, um ein einfaches Authentifizierungstoken zu erstellen. Fügen Sie schließlich dieses Skript zu Ihrer Pipeline hinzu:

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

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

Verwenden Sie eine geheime Variable in Ihrem Projekt, oder erstellen Sie die Pipeline, um das von Ihnen generierte Standardauthentifizierungstoken zu speichern. Verwenden Sie diese Variable, um den geheimen Schlüssel im obigen Git-Befehl aufzufüllen.

Synchronisierungstags

Der Auscheckschritt verwendet die option --tags beim Abrufen des Inhalts eines Git-Repositorys. Dadurch ruft der Server alle Tags sowie alle Objekte ab, auf die von diesen Tags verwiesen wird. Dies erhöht die Zeit zum Ausführen der Aufgabe in einer Pipeline, insbesondere wenn Sie über ein großes Repository mit einer Reihe von Tags verfügen. Darüber hinaus synchronisiert der Checkout-Schritt Tags auch dann, wenn Sie die Option für den flachen Abruf aktivieren und damit möglicherweise seinen Zweck besiegen. Um die Datenmenge zu reduzieren, die aus einem Git-Repository abgerufen oder abgerufen wurde, hat Microsoft eine neue Option zum Auschecken hinzugefügt, um das Verhalten der Synchronisierungstags zu steuern. Diese Option ist sowohl in klassischen als auch in YAML-Pipelines verfügbar.

Gibt an, ob Tags beim Auschecken eines Repositorys in YAML konfiguriert werden sollen, indem sie die eigenschaft fetchTags und auf der Benutzeroberfläche durch Konfigurieren der -Synchronisierungstags Einstellung konfigurieren.

steps:
- checkout: self
  fetchTags: true

Standardverhalten

• Für vorhandene Pipelines, die vor der Veröffentlichung von Azure DevOps Sprint 209erstellt wurden, die im September 2022 veröffentlicht wurde, bleibt die Standardeinstellung für Synchronisierungstags dasselbe wie das vorhandene Verhalten, bevor die -Synchronisierungstags Optionen hinzugefügt wurden, was trueist.
• Für neue Pipelines, die nach Azure DevOps Sprint Release 209 erstellt wurden, ist die Standardeinstellung für die Synchronisierung von Tags false.

Flacher Abruf

Möglicherweise möchten Sie einschränken, wie weit zurück der Verlauf zum Herunterladen ist. Dies führt effektiv zu git fetch --depth=n. Wenn Ihr Repository groß ist, kann diese Option ihre Buildpipeline effizienter gestalten. Ihr Repository ist möglicherweise groß, wenn es lange verwendet wurde und über einen großen Verlauf verfügt. Es 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 kann diese Option Ihnen helfen, Netzwerk- und Speicherressourcen zu sparen. Es kann auch Zeit sparen. Der Grund, warum es nicht immer Zeit spart, liegt daran, dass der Server in einigen Situationen Zeit für die Berechnung der Commits für die von Ihnen angegebene Tiefe aufwenden muss.

Quellen nicht synchronisieren

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

• Git init, config, and fetch using your own custom options.

• Verwenden Sie eine Buildpipeline, um die Automatisierung (z. B. einige Skripts) nur auszuführen, die nicht von Code in der Versionssteuerung abhängen.

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

Sauberer Build

Sie können verschiedene Formen des Bereinigens des Arbeitsverzeichnisses Ihres selbst gehosteten Agents durchführen, bevor ein Build ausgeführt wird.

Im Allgemeinen müssen Sie das Repository nicht bereinigen, um die Leistung Ihrer selbst gehosteten Agents zu beschleunigen. Um die beste Leistung zu erzielen, stellen Sie in diesem Fall sicher, dass Sie auch inkrementell erstellen, indem Sie alle Option zum Bereinigen der Aufgabe oder des Tools deaktivieren, die Sie zum Erstellen verwenden.

Wenn Sie das Repository bereinigen müssen (z. B. um Probleme zu vermeiden, die durch Restdateien aus einem vorherigen Build verursacht werden), finden Sie die folgenden Optionen.

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

Bezeichnungsquellen

Möglicherweise möchten Sie Ihre Quellcodedateien beschriften, damit Ihr Team ganz einfach erkennen kann, welche Version jeder Datei im abgeschlossenen Build enthalten ist. Sie haben auch die Möglichkeit, anzugeben, ob der Quellcode für alle Builds oder nur für erfolgreiche Builds beschriftet werden soll.

Im Tag-Format können Sie benutzerdefinierte und vordefinierte Variablen verwenden, die einen Bereich von "Alle" aufweisen. Zum Beispiel:

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

Die ersten vier Variablen sind vordefinierte. My.Variable können von Ihnen auf der Registerkarte Variablendefiniert werden.

Die Buildpipeline beschriftet Ihre Quellen mit einem Git-Tag.

Einige Buildvariablen können einen Wert liefern, 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 markiert wurden, wird dem abgeschlossenen Build automatisch ein Artefakt mit dem Git-Referenz-refs/tags/{tag} hinzugefügt. Dies ermöglicht Ihrem Team eine zusätzliche Rückverfolgbarkeit und eine benutzerfreundlichere Möglichkeit, vom Build zum erstellten Code zu navigieren. Das Tag wird als Buildartefakt betrachtet, da es vom Build erstellt wird. Wenn der Build manuell oder über eine Aufbewahrungsrichtlinie gelöscht wird, wird das Tag ebenfalls gelöscht.

Vordefinierte Variablen

Wenn Sie ein GitHub-Repository erstellen, stehen die meisten der vordefinierten Variablen für Ihre Aufträge zur Verfügung. Da Azure Pipelines jedoch die Identität eines Benutzers, der ein Update in GitHub vornimmt, nicht erkennt, werden die folgenden Variablen auf die Systemidentität und nicht auf die Identität des Benutzers festgelegt:

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

Statusaktualisierungen

Es gibt zwei Arten von Status, die Azure Pipelines zurück zu GitHub sendet – grundlegende Status und GitHub-Prüfläufe. GitHub-Überprüfungsfunktionen sind nur in GitHub-Apps verfügbar.

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

• Für PRs werden sie auf der Registerkarte "PR-Unterhaltungen" angezeigt.
• Bei einzelnen Commits werden sie angezeigt, wenn sie nach dem Commit auf der Registerkarte "Commits" des Repositorys mit dem Mauszeiger auf die Statusmarke zeigen.

PAT- oder OAuth-GitHub-Verbindungen

Bei Pipelines, die PAT oder OAuth GitHub-Verbindungen verwenden, werden Statuswerte an den Commit/PR zurückgesendet, der die Ausführung ausgelöst hat. Die GitHub-Status-API wird verwendet, um solche Updates zu veröffentlichen. Diese Status enthalten eingeschränkte Informationen: Pipelinestatus (fehlgeschlagen, Erfolg), URL zum Verknüpfen mit der Buildpipeline und eine kurze Beschreibung des Status.

Statuses für PAT- oder OAuth GitHub-Verbindungen werden nur auf Ausführungsebene gesendet. Mit anderen Worten, Sie können einen einzelnen Status für eine gesamte Ausführung aktualisiert haben. Wenn Sie über mehrere Aufträge in einer Ausführung verfügen, können Sie für jeden Auftrag keinen separaten Status bereitstellen. Mehrere Pipelines können jedoch separate Status für denselben Commit bereitstellen.

GitHub-Prüfungen

Für Pipelines, die mithilfe der Azure Pipelines GitHub-Appeingerichtet werden, wird der Status in Form von GitHub-Prüfungen zurückgesetzt. GitHub-Prüfungen ermöglichen das Senden detaillierter Informationen über den Pipelinestatus und den Test, die Codeabdeckung und Fehler. Die GitHub-Prüf-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ück gepostet.

GitHub ermöglicht drei Optionen, wenn eine oder mehrere Überprüfungsläufe für einen PR/Commit fehlschlagen. 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 anfangs erfolgreich waren oder nicht.

Wenn Sie auf den Link "Erneut ausführen" neben dem Namen "Ausführen überprüfen" klicken, wird die Ausführung von Azure Pipelines wiederholt, die die Überprüfungsausfü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 die Aufträge, die bei der ersten Ausführung fehlgeschlagen sind, und 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 "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 angezeigt und Änderungen in der Konfigurations- oder YAML-Datei aufgenommen.

Begrenzungen

• Für eine optimale Leistung empfehlen wir maximal 50 Pipelines in einem einzigen Repository. Für eine akzeptable Leistung empfehlen wir maximal 100 Pipelines in einem einzigen Repository. Die Zeit, die zum Verarbeiten eines Pushvorgangs an ein Repository erforderlich ist, erhöht sich mit der Anzahl der Pipelines in diesem Repository. Immer wenn ein Push an ein Repository erfolgt, muss Azure Pipelines alle YAML-Pipelines in diesem Repository laden, um herauszufinden, ob eine dieser Pipelines ausgeführt werden muss, und das Laden jeder Pipeline führt zu leistungseinbußen. Neben Leistungsproblemen kann das Vorhandensein von zu vielen Pipelines in einem einzigen Repository zu Drosselung auf GitHub-Seite führen, da Azure-Pipelines möglicherweise zu viele Anforderungen in kurzer Zeit ausführen.

• Die Verwendung von erweitert und enthalten Vorlagen in einer Pipeline auswirkungen auf die Rate, mit der Azure Pipelines GitHub-API-Anforderungen sendet und zu Drosselungen auf GitHub-Seite führen kann. Vor dem Ausführen einer Pipeline muss Azure Pipelines den vollständigen YAML-Code generieren, sodass alle Vorlagendateien abgerufen werden müssen.

• Azure Pipelines lädt maximal 2000 Verzweigungen aus einem Repository in Dropdownlisten im Azure DevOps-Portal, z. B. im Fenster Auswählen einer Verzweigung Fenster für die Standardverzweigung für manuelle und geplante Builds Einstellung oder beim Manuellen Auswählen einer Verzweigung.

  Wenn die gewünschte Verzweigung in der Liste nicht angezeigt wird, geben Sie den gewünschten Verzweigungsnamen manuell in die Standardverzweigung für manuelle und geplante Builds Feld ein.

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

Häufig gestellte Fragen

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

• Verbindungstypen: ich bin nicht sicher, welchen Verbindungstyp ich zum Verbinden meiner Pipeline mit GitHub verwende.
• Fehlerauslöser: Meine Pipeline wird nicht ausgelöst, wenn ich ein Update an das Repository pushe.
• Fehler beim Auschecken: Meine Pipeline wird ausgelöst, schlägt aber im Auscheckschritt fehl.
• Falsche Version: Meine Pipeline wird ausgeführt, verwendet jedoch eine unerwartete Version der Quelle/YAML.
• Fehlende Statusaktualisierungen: Meine GitHub-PRs werden blockiert, da Azure-Pipelines keine Statusaktualisierung meldeten.

Verbindungstypen

Wie kann ich den Typ der GitHub-Verbindung kennen, die ich für meine Pipeline verwende, um Probleme mit Triggern zu beheben?

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 Typ der Verbindung zu bestimmen – von GitHub und von Azure Pipelines.

• Von GitHub: Wenn ein Repository für die Verwendung der GitHub-App eingerichtet ist, werden die Status auf PRs und Commits überprüft. Wenn das Repository Azure-Pipelines mit OAuth- oder PAT-Verbindungen eingerichtet hat, sind die Status die "alte" Formatvorlage von Status. Eine schnelle Möglichkeit, zu ermitteln, ob die Status "Ausführen überprüfen" oder einfache Status sind, besteht darin, die Registerkarte "Unterhaltung" auf einer GitHub-PR anzuzeigen.

  • Wenn der Link "Details" zur Registerkarte "Prüfungen" umleitet, handelt es sich um eine Überprüfungsausführung, und das Repository verwendet die App.
  • Wenn der Link "Details" zur Azure DevOps-Pipeline umleitet, ist der Status ein Status "alter Stil", und das Repository verwendet die App nicht.

• Aus Azure-Pipelines: Sie können auch den Verbindungstyp ermitteln, indem Sie die Pipeline in der Benutzeroberfläche von Azure-Pipelines prüfen. Ö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 YAML-Registerkarte und dann den Schritt "Quellen abrufen" Schritt aus. Sie sehen ein Banner Autorisiert mithilfe der Verbindung: die Dienstverbindung angibt, die zum Integrieren der Pipeline in GitHub verwendet wurde. Der Name der Dienstverbindung ist ein Link. Wählen Sie sie aus, um zu den Dienstverbindungseigenschaften zu navigieren. Die Eigenschaften der Dienstverbindung geben den Typ der verwendeten Verbindung an:

  • Azure Pipelines-App gibt die GitHub-App-Verbindung an.
  • oauth- gibt die OAuth-Verbindung an.
  • personalaccesstoken gibt die PAT-Authentifizierung an.

Wie kann ich meine Pipeline wechseln, um die GitHub-App anstelle von OAuth zu verwenden?

Die Verwendung einer GitHub-App anstelle der 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 hier 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 Projekt auszuwählen. Wählen Sie die Organisation und das Projekt aus, die die klassische Buildpipeline enthalten, für die Sie die App verwenden möchten. Diese Option ordnet die GitHub-App-Installation Ihrer Azure DevOps-Organisation zu. Wenn Sie sich falsch entscheiden, können Sie dieser Seite besuchen, um die GitHub-App von Ihrer GitHub-Organisation zu deinstallieren und von vorne zu beginnen.
3. Auf der nächsten angezeigten Seite müssen Sie nicht mit dem Erstellen einer neuen Pipeline fortfahren.
4. Bearbeiten Sie Ihre Pipeline, indem Sie die Seite "Pipelines" besuchen (z. B. https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), Wählen Sie Ihre Pipeline aus, und klicken Sie auf "Bearbeiten".
5. Wenn es sich um eine YAML-Pipeline handelt, wählen Sie die Trigger Menü 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 mithilfe der Verbindung" "Ä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 Warteschleife" und dann "Speichern und Warteschlange" aus. Wählen Sie den Link zur Pipelineausführung aus, die in die Warteschlange gestellt wurde, um sicherzustellen, dass sie erfolgreich ist.
9. Erstellen (oder schließen und erneut öffnen) Sie eine Pullanforderung in Ihrem GitHub-Repository, um zu überprüfen, ob ein Build erfolgreich im Abschnitt "Prüfungen" in die Warteschlange gestellt wird.

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, lesen Sie GitHub-App-Authentifizierung.
• Wenn Sie OAuth verwenden, lesen Sie OAuth-Authentifizierung.
• Wenn Sie PATs verwenden, lesen Sie PAT-Authentifizierung (Personal Access Token).

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

Dies 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. Hier sind die Schritte, die Sie ausführen sollten, um die Zuordnung zur anderen Organisation zu entfernen, bevor Sie mit der Erstellung einer Pipeline fortfahren.

1. Öffnen Sie eine Pull-Anforderung in Ihrem GitHub-Repository, und nehmen Sie den Kommentar /azp where. Dies meldet die Azure DevOps-Organisation, der das Repository zugeordnet ist.

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

Fehlerauslöser

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

Führen Sie die folgenden Schritte aus, um Fehlerauslöser zu beheben:

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

  

  Überprüfen Sie die Den YAML-Trigger hier außer Kraft setzen, Einstellung für die Triggertypen (kontinuierliche Integration oder Pullanforderungsüberprüfung) für Ihr Repository verfügbar ist.

  

• Verwenden Sie die GitHub-App-Verbindung, um die Pipeline mit GitHub zu verbinden? Siehe Verbindungstypen, um den Verbindungstyp zu bestimmen, den Sie haben. 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 eine Pull-Anforderung in Ihrem GitHub-Repository, und nehmen Sie den Kommentar /azp where. Dies meldet die Azure DevOps-Organisation, 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. Wir haben derzeit die Einschränkung, dass wir nur ein GitHub-Repository einer einzelnen DevOps-Organisation zuordnen können. Nur die Pipelines in der ersten Azure DevOps-Organisation können automatisch ausgelöst werden. Um die Zuordnung zu ändern, deinstallieren Sie die App aus der GitHub-Organisation, und installieren Sie sie erneut. Stellen Sie beim erneuten Installieren 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? Siehe Verbindungstypen, um den Verbindungstyp zu bestimmen, den Sie haben. Wenn Sie eine GitHub-Verbindung verwenden, führen Sie die folgenden Schritte aus:

  1. OAuth- und PAT-Verbindungen basieren auf Webhooks, um Updates für Azure-Pipelines zu kommunizieren. Navigieren Sie in GitHub zu den Einstellungen für Ihr Repository und dann zu Webhooks. Stellen Sie sicher, dass die Webhooks vorhanden sind. In der Regel sollten drei Webhooks angezeigt werden : Push, pull_request und issue_comment. Andernfalls müssen Sie die Dienstverbindung erneut erstellen und die Pipeline aktualisieren, um die neue Dienstverbindung zu verwenden.

  2. Wählen Sie die einzelnen Webhooks in GitHub aus, und überprüfen Sie, ob die Nutzlast, 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 mit Azure DevOps kommuniziert werden konnte.

• Der Datenverkehr von Azure DevOps könnte von GitHub gedrosselt werden. Wenn Azure Pipelines eine Benachrichtigung von GitHub empfängt, versucht es, GitHub zu kontaktieren und weitere Informationen zur Repository- und YAML-Datei abzurufen. Wenn Sie über ein Repository mit einer großen Anzahl von Updates und Pullanforderungen verfügen, kann dieser Aufruf aufgrund einer solchen Drosselung fehlschlagen. Überprüfen Sie in diesem Fall, ob Sie die Häufigkeit von Builds reduzieren können, indem Sie Batchverarbeitungs- oder strengere Pfad-/Verzweigungsfilter verwenden.

• Ist Die Pipeline angehalten oder deaktiviert? Öffnen Sie den Editor für die Pipeline, und wählen Sie dann Einstellungen aus, überprüft werden soll. Wenn Die Pipeline angehalten oder deaktiviert ist, funktionieren Trigger nicht.

• Haben Sie die YAML-Datei in der richtigen Verzweigung aktualisiert? Wenn Sie ein Update an eine Verzweigung übertragen, steuert die YAML-Datei in derselben Verzweigung das CI-Verhalten. Wenn Sie eine Aktualisierung an einen Quellzweig übertragen, steuert die YAML-Datei, die sich aus dem Zusammenführen des Quellzweigs mit dem Zielzweig ergibt, das PR-Verhalten. Stellen Sie sicher, dass die YAML-Datei in der richtigen Verzweigung ü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 Include- als auch Ausschlussklauseln für Verzweigungen, Tags und Pfade angeben. Stellen Sie sicher, dass die Includeklausel mit den Details Ihres Commits übereinstimmt und dass die Ausschlussklausel sie nicht ausschließt. Überprüfen Sie die Syntax für die Trigger, und stellen Sie sicher, dass sie korrekt ist.

• Haben Sie Variablen beim Definieren des Triggers oder der Pfade verwendet? Das wird nicht unterstützt.

• Haben Sie Vorlagen für Ihre YAML-Datei verwendet? Stellen Sie in diesem Fall sicher, dass Ihre Trigger in der YAML-Hauptdatei definiert sind. Trigger, die in Vorlagendateien definiert sind, werden nicht unterstützt.

• Haben Sie die Verzweigungen oder Pfade ausgeschlossen, an die Sie Ihre Änderungen übertragen haben? Testen Sie, indem Sie eine Änderung an einen eingeschlossenen Pfad in einer eingeschlossenen Verzweigung übertragen. Beachten Sie, dass Pfade in Triggern groß-/kleinschreibung beachten. Stellen Sie sicher, dass Sie beim Angeben der Pfade in Triggern den gleichen Fall wie die tatsächlichen Ordner verwenden.

• Haben Sie gerade einen neuen Zweig verschoben? Wenn ja, startet die neue Verzweigung möglicherweise keine neue Ausführung. Weitere Informationen finden Sie im Abschnitt "Verhalten von Triggern, wenn neue Verzweigungen erstellt werden".

Meine CI- oder PR-Trigger funktionieren gut. Aber sie funktionieren jetzt nicht mehr.

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

• Haben Sie In Ihrer PR Konflikte zusammenführen? Öffnen Sie für eine PR, die keine Pipeline ausgelöst hat, sie, und überprüfen Sie, ob ein Zusammenführungskonflikt vorliegt. Lösen Sie den Zusammenführungskonflikt.

• Kommt es zu einer Verzögerung bei der Verarbeitung von Push- oder PR-Ereignissen? In der Regel können Sie eine Verzögerung überprüfen, indem Sie feststellen, ob das Problem für eine einzelne Pipeline spezifisch ist oder für alle Pipelines oder Repositorys in Ihrem Projekt üblich ist. Wenn ein Push- oder PR-Update auf eines der Reposs dieses Symptom aufweist, treten möglicherweise Verzögerungen bei der Verarbeitung der Updateereignisse auf. Hier sind einige Gründe, warum eine Verzögerung auftreten kann:

  • Wir erleben einen Dienstausfall auf unserer Statusseite. Wenn auf der Statusseite ein Problem angezeigt wird, muss unser Team bereits damit begonnen haben, daran zu arbeiten. Überprüfen Sie die Seite häufig auf Updates für das Problem.
  • Ihr Repository enthält zu viele YAML-Pipelines. Für eine optimale Leistung empfehlen wir maximal 50 Pipelines in einem einzigen Repository. Für eine akzeptable Leistung empfehlen wir maximal 100 Pipelines in einem einzigen Repository. Je mehr Pipelines vorhanden sind, desto langsamer wird die Verarbeitung eines Pushs an dieses Repository. Immer wenn ein Push an ein Repository erfolgt, 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 die Liste der Verzweigungen für Trigger außer Kraft setzen, wenn sie die YAML-Datei aktualisieren. Wie kann ich dies tun?

Benutzer mit Berechtigungen zum Mitwirken von Code können die YAML-Datei aktualisieren und zusätzliche Verzweigungen einschließen/ausschließen. Daher können Benutzer ihre eigene Funktion oder Benutzerzweigung in ihre YAML-Datei einschließen und diese Aktualisierung an ein Feature oder einen Benutzerzweig übertragen. Dies kann dazu führen, dass die Pipeline für alle Updates für diese Verzweigung ausgelöst wird. Wenn Sie dieses Verhalten verhindern möchten, können Sie:

1. Bearbeiten Sie die Pipeline in der Benutzeroberfläche von Azure Pipelines.
2. Navigieren Sie zum Menü Trigger.
3. Wählen Sie Den YAML-Endlosintegrationsauslöser von hieraußer Kraft setzen.
4. Geben Sie die Verzweigungen an, die für den Trigger eingeschlossen oder ausgeschlossen werden sollen.

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

Fehlerhaftes Auschecken

Beim Auschecken wird der folgende Fehler in der Protokolldatei angezeigt. Wie kann ich es beheben?

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

Dies könnte durch einen Ausfall von GitHub verursacht werden. Versuchen Sie, auf das Repository in GitHub zuzugreifen, und stellen Sie sicher, dass Sie in der Lage sind.

Falsche Version

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

• Bei CI-Triggern wird die YAML-Datei, die sich in der verzweigten Verzweigung befindet, ausgewertet, um festzustellen, ob ein CI-Build ausgeführt werden soll.
• Bei PR-Triggern wird die YAML-Datei, die sich aus dem Zusammenführen der Quell- und Zielzweige der PR ergibt, ausgewertet, um festzustellen, ob ein PR-Build ausgeführt werden soll.

Fehlende Statusaktualisierungen

Meine PR in GitHub ist blockiert, da Azure Pipelines den Status nicht aktualisiert haben.

Dies kann ein vorübergehender Fehler sein, der dazu führte, dass Azure DevOps nicht mit GitHub kommunizieren kann. Wiederholen Sie das Einchecken von GitHub, wenn Sie die GitHub-App verwenden. Oder machen Sie eine triviale Aktualisierung der PR, um festzustellen, ob das Problem behoben werden kann.

Verwandte Artikel

• geplanten Trigger
• Pipelineabschluss löst