Erstellen von Bitbucket Cloud-Repositorys

Azure DevOps Services

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

Bitbucket- und Azure-Pipelines sind zwei unabhängige Dienste, die gut zusammen integriert werden. Ihre Bitbucket-Cloudbenutzer erhalten nicht automatisch Zugriff auf Azure-Pipelines. Sie müssen sie explizit zu Azure Pipelines hinzufügen.

Zugriff auf Bitbucket-Repositorys

YAML

Sie erstellen eine neue Pipeline, indem Sie zuerst ein Bitbucket-Cloud-Repository und dann eine YAML-Datei in diesem Repository auswählen. Das Repository, in dem die YAML-Datei vorhanden ist, wird self Repository genannt. Standardmäßig ist dies das Repository, das Ihre Pipeline erstellt.

Sie können Ihre Pipeline später so konfigurieren, dass sie ein anderes Repository oder mehrere Repositorys auschecken. Informationen dazu finden Sie unter Multi-Repo-Auschecken.

Klassisch

Sie erstellen eine neue Pipeline, indem Sie zuerst Bitbucket Cloud- für den Repositorytyp und dann eines der Repositorys auswählen, auf die Sie Zugriff haben.

Azure-Pipelines müssen Zugriff auf Ihre Repositorys erhalten, um den Code während der Builds abzurufen. Darüber hinaus muss der Benutzer, der die Pipeline eingerichtet hat, Über Administratorzugriff auf Bitbucket verfügen, da diese Identität zum Registrieren eines Webhooks in Bitbucket verwendet wird.

Es gibt zwei Authentifizierungstypen zum Gewähren des Zugriffs auf Ihre Bitbucket-Cloudrepositorys bei der Erstellung einer Pipeline.

Authentifizierungstyp	Pipelines werden mit
1. OAuth-	Ihre persönliche Bitbucket-Identität
2. Benutzernamen und Kennwort	Ihre persönliche Bitbucket-Identität

OAuth-Authentifizierung

OAuth ist der einfachste Authentifizierungstyp, mit dem Sie mit Repositorys in Ihrem Bitbucket-Konto beginnen können. Bitbucket-Statusaktualisierungen werden im Namen Ihrer persönlichen Bitbucket-Identität ausgeführt. Damit Pipelines weiterhin funktionieren, muss ihr Repositoryzugriff aktiv bleiben.

Um OAuth zu verwenden, melden Sie sich bei Bitbucket an, wenn Sie während der Pipelineerstellung dazu aufgefordert werden. Klicken Sie dann auf Autorisieren, um OAuth zu autorisieren. Eine OAuth-Verbindung wird in Ihrem Azure DevOps-Projekt zur späteren Verwendung gespeichert und in der zu erstellenden Pipeline verwendet.

Hinweis

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

Kennwortauthentifizierung

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

Um eine Kennwortverbindung zu erstellen, besuchen Sie Dienstverbindungen in Ihren Azure DevOps-Projekteinstellungen. Erstellen Sie eine neue Bitbucket-Dienstverbindung, und stellen Sie den Benutzernamen und das Kennwort bereit, um eine Verbindung mit Ihrem Bitbucket Cloud-Repository herzustellen.

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.

YAML

YAML-Pipelines werden standardmäßig mit einem CI-Trigger in allen Zweigen konfiguriert, es sei denn, der Deaktivieren implizierter YAML CI-Trigger Einstellung, eingeführt in Azure DevOps Sprint 227, ist aktiviert. Die Deaktivieren implizierter YAML CI-Trigger Einstellung kann auf Organisationsebene oder auf Projektebene konfiguriert werden. Wenn die konkludente YAML CI-Trigger deaktivieren Einstellung aktiviert ist, werden CI-Trigger für YAML-Pipelines nicht aktiviert, wenn die YAML-Pipeline keinen trigger Abschnitt enthält. Standardmäßig ist konkludente YAML CI-Trigger deaktivieren, nicht aktiviert ist.

Zweige

Sie können steuern, welche Verzweigungen CI-Trigger mit einer einfachen Syntax erhalten:

trigger:
- main
- releases/*

Sie können den vollständigen Namen der Verzweigung (z. B. main) oder einen Wildcard (z. B. releases/*) angeben. Informationen zur Wildcardsyntax finden Sie unter Wildcards.

Hinweis

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

Hinweis

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

Für komplexere Trigger, die exclude oder batchverwenden, 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 eine verzweigte Version verschoben wird. Es wird jedoch nicht ausgelöst, wenn eine Änderung an einem Release Branch vorgenommen wird, der mit oldbeginnt.

Wenn Sie eine exclude-Klausel ohne include-Klausel angeben, entspricht sie der Angabe von * in der include-Klausel.

Neben der Angabe von Verzweigungsnamen in den branches Listen können Sie auch Trigger basierend auf Tags mithilfe des folgenden Formats konfigurieren:

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

Wenn Sie keine Trigger angegeben haben und die Deaktivieren implizierter YAML CI-Trigger Einstellung nicht aktiviert ist, ist die Standardeinstellung wie geschrieben:

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

Wichtig

Wenn Sie einen Trigger angeben, wird der implizite Standardtrigger ersetzt, und nur Pushes an Verzweigungen, die explizit konfiguriert sind, lösen eine Pipeline aus. Schließt zuerst ab und schließt dann aus dieser Liste aus.

Batchverarbeitungs-CI-Ausführung

Wenn Sie viele Teammitglieder häufig Änderungen hochladen, können Sie die Anzahl der gestarteten Ausführungen verringern. Wenn Sie batch auf truefestlegen, wartet das System, wenn eine Pipeline ausgeführt wird, bis die Ausführung abgeschlossen ist, und startet dann eine weitere Ausführung mit allen Änderungen, die noch nicht erstellt wurden.

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

Hinweis

batch wird in Triggern für Repositoryressourcen nicht unterstützt.

Um dieses Beispiel zu verdeutlichen, sagen wir, dass ein Push-A auf main verursacht hat, dass die oben genannte Pipeline ausgeführt wurde. Während diese Pipeline ausgeführt wird, treten im Repository zusätzliche Pushs B und C auf. Diese Updates starten keine neuen unabhängigen Ausführung sofort. Nach Abschluss der ersten Ausführung werden jedoch alle Pushs bis zu diesem Zeitpunkt zusammengebatt und eine neue Ausführung gestartet.

Hinweis

Wenn die Pipeline über mehrere Aufträge und Stufen verfügt, sollte die erste Ausführung trotzdem einen Terminalzustand erreichen, indem alle Aufträge und Phasen abgeschlossen oder übersprungen werden, bevor die zweite Ausführung gestartet werden kann. Aus diesem Grund müssen Sie bei der Verwendung dieses Features in einer Pipeline mit mehreren Phasen oder Genehmigungen Vorsicht walten lassen. Wenn Sie Ihre Builds in solchen Fällen stapeln möchten, empfiehlt es sich, Den CI/CD-Prozess in zwei Pipelines aufzuteilen – eine für build (mit Batchverarbeitung) und eine für Bereitstellungen.

Pfade

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

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

Wenn Sie Pfade angeben, müssen Sie explizit Verzweigungen angeben, die ausgelöst werden sollen, wenn Sie Azure DevOps Server 2019.1 oder niedriger verwenden. Sie können eine Pipeline nicht nur mit einem Pfadfilter auslösen. Sie müssen auch über einen Verzweigungsfilter verfügen, und die geänderten Dateien, die dem Pfadfilter entsprechen, müssen aus einer Verzweigung stammen, die dem Verzweigungsfilter entspricht. Wenn Sie Azure DevOps Server 2020 oder höher verwenden, können Sie branches weglassen, um in Verbindung mit dem Pfadfilter nach allen Verzweigungen zu filtern.

Wilds-Karten werden für Pfadfilter unterstützt. Sie können beispielsweise alle Pfade einschließen, die src/app/**/myapp*entsprechen. Beim Angeben von Pfadfiltern können Sie Wildcardzeichen (**, *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 auch nicht einschließen, es sei denn, Sie qualifizieren ihn für einen tieferen Ordner. Wenn Sie z. B. /tools ausschließen, können Sie /tools/trigger-runs-on-these
• Die Reihenfolge der Pfadfilter spielt keine Rolle.
• Pfade in Git-beachten die Groß-/Kleinschreibung. Achten Sie darauf, den gleichen Fall wie die echten Ordner zu verwenden.
• Sie können Variablen nicht in Pfaden verwenden, da Variablen zur Laufzeit ausgewertet werden (nachdem der Trigger ausgelöst wurde).

Hinweis

Bei Bitbucket Cloud-Repositorys ist die Verwendung branches Syntax die einzige Möglichkeit zum Angeben von Tagtriggern. Die tags: syntax wird für Bitbucket nicht unterstützt.

Abmelden von CI

Deaktivieren des CI-Triggers

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

# A pipeline with no CI trigger
trigger: none

Wichtig

Wenn Sie eine Änderung an eine Verzweigung übertragen, wird die YAML-Datei in dieser Verzweigung ausgewertet, um zu ermitteln, ob eine CI-Ausführung gestartet werden soll.

Klassisch

Hinweis

Die Build.SourceVersionMessage- Variable funktioniert nicht mit Bitbucket-Repositorys, wenn Batchänderungen ausgeführt werden, während ein Build ausgeführt wird, aktiviert ist.

Wählen Sie Aktivieren der kontinuierlichen Integration auf der Registerkarte Trigger, um diesen Trigger zu aktivieren, wenn der Build ausgeführt werden soll, wenn jemand Code eincheckt.

Batchänderungen

Aktivieren Sie dieses Kontrollkästchen, wenn Viele Teammitglieder Änderungen häufig hochladen und die Anzahl der Builds verringern möchten, die Sie ausführen. Wenn Sie diese Option auswählen, wartet das System, wenn ein Build ausgeführt wird, bis die Ausführung abgeschlossen ist, und wartet dann eine andere Ausführung aller Noch nicht erstellten Änderungen in die Warteschlange.

Sie können Änderungen stapeln und zusammen erstellen.

Hinweis

Wenn Sie batching mit einer mehrstufigen YAML-Pipeline verwenden, muss eine Ausführung einen Terminalzustand erreichen, bevor die nächste gestartet werden kann. Dies ist häufig nicht wünschenswert, da eine mehrstufige Pipeline genehmigungen und lange Bereitstellungsphasen durchlaufen kann. In diesen Fällen wird empfohlen, eine der folgenden Lösungen zu befolgen:

• Batchverarbeitung nicht verwenden
• Aufteilen der Pipeline in zwei separate Pipelines – eine für CI und eine CD
• Legen Sie geeignete Bedingungen für Phasen fest, um sie zu überspringen und eine Ausführung schnell zu beenden

Verzweigungsfilter

Sie können die Verzweigungen angeben, an denen Sie Builds auslösen möchten. Wenn Sie Wildcardzeichen verwenden möchten, geben Sie die Verzweigungsspezifikation (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 den Satz von Dateien zu reduzieren, die Sie einen Build auslösen möchten.

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 auch nicht einschließen, es sei denn, Sie qualifizieren ihn für einen tieferen Ordner. Wenn Sie z. B. /tools ausschließen, können Sie /tools/trigger-runs-on-these
• Die Reihenfolge der Pfadfilter spielt keine Rolle.
• Bei Pfaden in Git wird die Groß-/Kleinschreibung beachtet. Achten Sie darauf, den gleichen Fall wie die echten Ordner zu verwenden.

Beispiel

Sie möchten z. B., dass Ihr Build durch Änderungen in main und den meisten, aber nicht alle Ihrer Featurezweige ausgelöst wird. Sie möchten auch nicht, dass Builds durch Änderungen an Dateien im Toolsordner 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 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, wenn neue Verzweigungen verschoben werden

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.

YAML

Zweige

Sie können die Zielzweige angeben, wenn Sie Ihre Pullanforderungen überprüfen. Um beispielsweise Pullanforderungen zu überprüfen, die auf master und releases/*abzielen, können Sie den folgenden pr Trigger verwenden.

pr:
- main
- releases/*

Diese Konfiguration startet eine neue Ausführung, wenn eine neue Pullanforderung zum ersten Mal erstellt wird, und nach jeder Aktualisierung, die an der Pullanforderung vorgenommen wurde.

Sie können den vollständigen Namen der Verzweigung (z. B. master) oder einen Wildcard (z. B. releases/*) angeben.

Hinweis

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

Hinweis

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

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

Wenn in Ihrer YAML-Datei keine pr Trigger angezeigt werden, werden Pullanforderungsüberprüfungen automatisch für alle Verzweigungen aktiviert, als ob Sie den folgenden pr Trigger geschrieben haben. Diese Konfiguration löst einen Build aus, wenn eine Pullanforderung erstellt wird, und wenn Commits in den Quellzweig jeder aktiven Pullanforderung gelangen.

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

Wichtig

Wenn Sie einen pr Trigger angeben, wird der implizite pr-Standardauslöser ersetzt, und nur Pushes an Verzweigungen, die explizit konfiguriert sind, lösen eine Pipeline aus.

Für komplexere Trigger, die bestimmte Verzweigungen 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*

Pfade

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

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

Tipps:

• Wildcards werden mit Pfadfiltern nicht unterstützt.
• Pfade werden immer relativ zum Stammverzeichnis des Repositorys angegeben.
• Wenn Sie keine Pfadfilter festlegen, wird der Stammordner des Repositorys standardmäßig implizit eingeschlossen.
• Wenn Sie einen Pfad ausschließen, können Sie ihn auch nicht einschließen, es sei denn, Sie qualifizieren ihn für einen tieferen Ordner. Wenn Sie z. B. /tools ausschließen, können Sie /tools/trigger-runs-on-these
• Die Reihenfolge der Pfadfilter spielt keine Rolle.
• Pfade in Git-beachten die Groß-/Kleinschreibung. Achten Sie darauf, den gleichen Fall wie die echten Ordner zu verwenden.
• Sie können Variablen nicht 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 Aktualisierungen für eine PR die laufende Überprüfung für dieselbe PR abbrechen sollen. Der Standardwert ist true.

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

Abmelden der PR-Validierung

Sie können die Pull-Anforderungsüberprüfung vollständig deaktivieren, indem Sie pr: noneangeben.

# 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 in der BEnutzeroberfläche keine YAML-PR-Triggerüberschrieben haben.

Klassisch

Aktivieren Sie das Kontrollkästchen Pullanforderungsüberprüfung Trigger, und aktivieren Sie das Kontrollkästchen Überprüfung der Pullanforderung aktivieren, um Builds für Pullanforderungen zu aktivieren.

Sie können Verzweigungen angeben, die eingeschlossen und ausgeschlossen werden sollen. Wählen Sie im Dropdownmenü einen Verzweigungsnamen aus, und wählen Sie Einschließen von oder ausschließen aus. Für enthaltene Verzweigungen wird ein Build auf jedem Push an eine Pullanforderung ausgelöst, die auf diese Verzweigung ausgerichtet ist.

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.

Einschränkungen

Azure Pipelines lädt maximal 2000 Verzweigungen aus einem Repository in Dropdownlisten im Azure Devops-Portal, z. B. in den Default Branch für manuelle und geplante Builds Einstellung oder beim Manuellen Ausführen einer Pipeline. 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 sind in die folgenden Kategorien unterteilt:

• Fehlerauslöser: Meine Pipeline wird nicht ausgelöst, wenn ich ein Update an das Repository pushe.
• Falsche Version: Meine Pipeline wird ausgeführt, verwendet jedoch eine unerwartete Version der Quelle/YAML.

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.

  

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

• 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 durch. Führen Sie dann die folgenden zusätzlichen Schritte aus:

• Haben Sie In Ihrer PR Konflikte zusammenführen? Öffnen Sie eine Pr-Datei, die keine Pipeline ausgelöst hat, 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? Sie können dies in der Regel überprüfen, indem Sie sehen, ob das Problem spezifisch für eine einzelne Pipeline 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. Überprüfen Sie, ob ein 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.

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.

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.