Erstellen von Bitbucket Cloud-Repositorys

Azure DevOps Services

Azure Pipelines kann automatisch jeden Pull Request erstellen und überprüfen und in Ihr Bitbucket Cloud-Repository committen. In diesem Artikel wird beschrieben, wie Sie die Integration zwischen Bitbucket Cloud und Azure Pipelines konfigurieren.

Bitbucket Cloud und Azure Pipelines sind zwei voneinander unabhängige Dienste, die gut zusammenarbeiten. Ihre Bitbucket Cloud-Benutzer erhalten nicht automatisch Zugriff auf Azure Pipelines. Sie müssen sie explizit zu Azure Pipelines hinzufügen.

Zugreifen auf Bitbucket-Repository

YAML

Sie erstellen eine neue Pipeline, indem Sie zunächst ein Bitbucket Cloud-Repository und dann eine YAML-Datei in diesem Repository auswählen. Das Repository, in dem sich die YAML-Datei befindet, wird als self-Repository bezeichnet. Standardmäßig ist dies das Repository, das Ihre Pipeline erstellt.

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

Klassisch

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

Azure Pipelines muss Zugriff auf Ihre Repositorys gewährt werden, um den Code während der Buildvorgänge abrufen zu können. Darüber hinaus muss der Benutzer, der die Pipeline einrichtet, über den Administratorzugriff für Bitbucket verfügen, da diese Identität verwendet wird, um einen Webhook in Bitbucket zu registrieren.

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

Authentifizierungsart	Pipelines werden mithilfe von Folgendem ausgeführt:
1. OAuth	Ihre persönliche Bitbucket-Identität
2. Benutzername und Kennwort	Ihre persönliche Bitbucket-Identität

OAuth-Authentifizierung

OAuth ist die einfachste Art der Authentifizierung für Repositorys in Ihrem Bitbucket-Konto. Bitbucket-Statusaktualisierungen werden im Namen Ihrer persönlichen Bitbucket-Identität durchgeführt. Damit die Pipelines weiterhin funktionieren, muss Ihr Repositoryzugriff aktiv bleiben.

Für die Verwendung von OAuth melden Sie sich bei Bitbucket an, wenn Sie bei der Erstellung der Pipeline dazu aufgefordert werden. Klicken Sie dann auf Autorisieren, um OAuth für die Autorisierung zu verwenden. Eine OAuth-Verbindung wird zur späteren Verwendung in Ihrem Azure DevOps-Projekt gespeichert und in der zu erstellenden Pipeline verwendet.

Hinweis

Die maximale Anzahl der Bitbucket-Repositorys, die von der Benutzeroberfläche von Azure DevOps Services geladen werden kann, beträgt 2.000.

Kennwortauthentifizierung

Builds und Bitbucket-Statusaktualisierungen werden im Namen Ihrer persönlichen Identität durchgeführt. Damit Builds weiterhin funktionieren, muss Ihr Repositoryzugriff aktiv bleiben.

Besuchen Sie Dienstverbindungen in Ihren Azure DevOps-Projekteinstellungen, um eine Kennwortverbindung zu erstellen. Erstellen Sie eine neue Bitbucket-Dienstverbindung, und geben Sie den Benutzernamen und das Kennwort für die Verbindung mit Ihrem Bitbucket Cloud-Repository an.

CI-Trigger

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

YAML

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

Branches

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

trigger:
- main
- releases/*

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

Hinweis

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

Hinweis

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

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

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

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

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

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

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

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

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

Wichtig

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

Batchverarbeitung von CI-Ausführungen

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

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

Hinweis

batch wird in Repositoryressourcentriggern nicht unterstützt.

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

Hinweis

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

Paths

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

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

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

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

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

Hinweis

Für Bitbucket Cloud-Repositorys ist die Verwendung der branches-Syntax die einzige Möglichkeit, Tagtrigger anzugeben. Die tags:-Syntax wird für Bitbucket nicht unterstützt.

Deaktivieren von CI

Deaktivieren des CI-Triggers

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

# A pipeline with no CI trigger
trigger: none

Wichtig

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

Klassisch

Hinweis

Die Build.SourceVersionMessage-Variable funktioniert nicht mit Bitbucket-Repositorys, wenn Batchänderungen während der Durchführung eines Builds aktiviert ist.

Wenn der Build ausgeführt werden soll, sobald jemand Code eincheckt, aktivieren Sie diesen Trigger, indem Sie auf der Registerkarte Trigger die Option Continuous Integration aktivieren auswählen.

Batchänderungen

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

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

Hinweis

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

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

Branchfilter

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

Pfadfilter

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

Tipps:

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

Beispiel

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

Überspringen von CI für einzelne Commits

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

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

Verwenden des Triggertyps in Bedingungen

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

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

Verhalten von Triggern beim Erstellen neuer Branches

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

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

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

Platzhalter

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

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

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

PR-Trigger (Pull Request)

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

YAML

Branches

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

pr:
- main
- releases/*

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

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

Hinweis

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

Hinweis

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

Jede neue Ausführung erstellt den neuesten Commit aus dem Quellbranch des Pull Requests. Dies unterscheidet sich von der Art und Weise, wie Azure Pipelines Pull Requests in anderen Repositorys (z. B. Azure Repos oder GitHub) erstellt, wo der Mergecommit erstellt wird. Leider macht Bitbucket keine Informationen über den Mergecommit verfügbar, der den zusammengeführten Code zwischen dem Quell- und Zielbranch des Pull Requests enthält.

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

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

Wichtig

Wenn Sie einen pr-Trigger angeben, ersetzt dieser den impliziten pr-Trigger, und nur Pushes an Branches, die explizit zum Einschließen konfiguriert sind, lösen eine Pipeline aus.

Für komplexere Trigger, die bestimmte Branches ausschließen müssen, müssen Sie die vollständige Syntax verwenden, wie im folgenden Beispiel gezeigt.

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

Paths

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

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

Tipps:

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

Mehrere PR-Updates

Sie können angeben, ob zusätzliche Updates für einen PR aktive Ausführungen von Überprüfungen für denselben PR abbrechen sollen. Der Standardwert lautet true.

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

Deaktivieren der PR-Überprüfung

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

# no PR triggers
pr: none

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

Hinweis

Wenn Ihr pr-Trigger nicht ausgelöst wird, stellen Sie sicher, dass Sie keine YAML-PR-Trigger auf der Benutzeroberfläche überschrieben haben.

Klassisch

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

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

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.

Begrenzungen

Azure Pipelines lädt maximal 2000 Verzweigungen aus einem Repository in Dropdownlisten im Azure Devops-Portal, z. B. in die Standardverzweigung für manuelle und geplante Builds oder beim Auswählen einer Verzweigung, wenn eine Pipeline manuell ausgeführt wird. Wenn die gewünschte Verzweigung in der Liste nicht angezeigt wird, geben Sie den gewünschten Verzweigungsnamen manuell ein.

Häufig gestellte Fragen

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

• Fehlende Trigger: Meine Pipeline wird nicht ausgelöst, wenn ich ein Update in das Repository pushe.
• Falsche Version: Meine Pipeline wird ausgeführt, aber es wird eine unerwartete Quell-/YAML-Version verwendet.

Triggerfehler

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

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

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

  

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

  

• Webhooks werden verwendet, um Updates von Bitbucket an Azure Pipelines zu übermitteln. Navigieren Sie in Bitbucket zu den Einstellungen für Ihr Repository und dann zu Webhooks. Vergewissern Sie sich, dass die Webhooks vorhanden sind.

• 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. Führen Sie 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 dies überprüfen, indem Sie ermitteln, 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. Überprüfen Sie auf unserer Statusseite, ob ein Dienstausfall vorliegt. 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.

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.

Falsche Version

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

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