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

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.

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.

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.

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

# A pipeline with no CI trigger
trigger: none

Überspringen von CI für einzelne Commits

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

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

Verwenden des Triggertyps in Bedingungen

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

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

Verhalten von Triggern beim Erstellen neuer Branches

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

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

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

Platzhalter

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

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

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

PR-Trigger (Pull Request)

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

pr:
- main
- releases/*

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

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

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

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

# no PR triggers
pr: none

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.