Erstellen von Azure Repos-Git- oder TFS-Git-Repositorys

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Azure Pipelines kann jeden Pull Request automatisch erstellen und überprüfen und einen Commit für Ihr Azure Repos Git-Repository erstellen.

Auswählen eines Repositorys zum Erstellen

YAML

Zum Erstellen einer neuen Pipeline wählen Sie zunächst ein Repository und dann eine YAML-Datei in diesem Repository aus. 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

Um beim Erstellen einer Pipeline das zu erstellende Repository auszuwählen, wählen Sie zunächst das Projekt aus, zu dem das Repository gehört. Anschließend wählen Sie das Repository aus.

So klonen Sie zusätzliche Repositorys als Teil Ihrer Pipeline

• Wenn sich das Repository im selben Projekt wie Ihre Pipeline befindet oder das Zugriffstoken (unten erläutert) in einem anderen Projekt Zugriff auf das Repository hat, verwenden Sie den folgenden Befehl:

  git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" <clone URL>

  Damit Sie das System.AccessToken in einem Skript verwenden können, müssen Sie es zuerst für das Skript verfügbar machen. Wählen Sie hierzu im Editor auf der Registerkarte Aufgaben den Auftrag und dann im rechten Bereich Zusätzliche Optionen aus, und aktivieren Sie die Option Skripts den Zugriff auf das OAuth-Token erlauben.

• Wenn das Zugriffstoken (unten erläutert) keinen Zugriff auf das Repository hat:

  1. Rufen Sie ein persönliches Zugriffstoken (Personal Access Token, PAT) mit dem Bereich Code (read) ab, und stellen Sie ihm PAT: voran.
  2. Codieren Sie diese Zeichenfolge mit Base64, um ein Standardauthentifizierungstoken zu erstellen.
  3. Fügen Sie Ihrer Pipeline mit dem folgenden Befehl ein Skript hinzu, um dieses Repository zu klonen: git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

Azure Pipelines muss Zugriff auf Ihre Repositorys erhalten, um die Builds auszulösen und bei den Buildvorgängen den entsprechenden Code abzurufen. Normalerweise hat eine Pipeline Zugriff auf Repositorys im selben Projekt. Wenn Sie jedoch auf Repositorys in einem anderen Projekt zugreifen möchten, müssen Sie die Berechtigungen aktualisieren, die Auftragszugriffstoken erteilt werden.

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

Tags

Sie können nicht nur Tags in den branches-Listen angeben, wie im vorherigen Abschnitt beschrieben, sondern ein- und auszuschließende Tags auch direkt festlegen:

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

Wenn Sie keine Tagtrigger angeben, lösen Tags standardmäßig keine Pipelines aus.

Wichtig

Wenn Sie Tags in Kombination mit Branchfiltern angeben, wird der Trigger ausgelöst, wenn entweder der Branchfilter oder der Tagfilter übereinstimmt. Wenn ein gepushtes Tag z. B. mit dem Branchfilter übereinstimmt, wird die Pipeline auch dann ausgelöst, wenn das Tag durch den Tagfilter ausgeschlossen ist, da der Push dem Branchfilter entspricht.

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

Wählen Sie auf der Registerkarte Trigger die Option Continuous Integration aktivieren aus, um diesen Trigger zu aktivieren, wenn der Build ausgeführt werden soll, sobald jemand Code eincheckt.

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 Pushes

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

Pull Request-Trigger (PR)

Pull Request-Trigger (PR) bewirken, dass eine Pipeline ausgeführt wird, wenn Sie einen Pull Request öffnen oder Änderungen an ihn pushen. In Azure Repos Git wird diese Funktionalität mithilfe von Branchrichtlinien implementiert. Navigieren Sie zum Aktivieren der PR-Überprüfung zu den Branchrichtlinien für den gewünschten Branch, und konfigurieren Sie die Buildüberprüfungsrichtlinie für diesen Branch. Weitere Informationen finden Sie unter Konfigurieren von Branchrichtlinien.

Wenn Sie einen offenen Pull Request haben und Änderungen an den zugehörigen Quellbranch pushen, können mehrere Pipelines ausgeführt werden:

• Die Pipelines, die in der Buildüberprüfungsrichtlinie des Zielbranches angegeben sind, werden im Mergecommit (gemergter Code zwischen den Quell- und Zielbranches des Pull Requests) ausgeführt, unabhängig davon, ob gepushte Commits vorhanden sind, deren Nachrichten oder Beschreibungen [skip ci] (oder Varianten davon) enthalten.
• Die Pipelines werden durch Änderungen am Quellbranch des Pull Requests ausgelöst, wenn keine gepushten Commits vorhanden sind, deren Nachrichten oder Beschreibungen [skip ci] (oder Varianten davon) enthalten. Wenn mindestens ein gepushter Commit [skip ci] enthält, werden die Pipelines nicht ausgeführt.

Nachdem Sie die Pull Requests gemergt haben, führt Azure Pipelines die CI-Pipelines aus, die durch Pushes an den Zielbranch ausgelöst werden, auch wenn einige der Nachrichten oder Beschreibungen des gemergten Commits [skip ci] (oder Varianten davon) enthalten.

Hinweis

Validierungsbuilds für ein Azure Repos-Git-Repository können nur von Projektadministrator*innen des jeweiligen Projekts konfiguriert werden.

Hinweis

Pull Request-Entwürfe lösen auch dann keine Pipeline aus, wenn Sie eine Branchrichtlinie konfigurieren.

Überprüfen der Beiträge aus Forks

Das Erstellen von Pull Requests aus Azure Repos-Forks unterscheidet sich nicht vom Erstellen von Pull Requests innerhalb desselben Repositorys oder Projekts. Sie können Forks nur innerhalb der Organisation erstellen, zu der Ihr Projekt gehört.

Begrenzen des Auftragsautorisierungsbereichs

Azure Pipelines bietet mehrere Sicherheitseinstellungen zum Konfigurieren des Auftragsautorisierungsbereichs, mit dem Ihre Pipelines ausgeführt werden.

• Autorisierungsbereich für Auftrag auf aktuelles Projekt begrenzen
• Zugriff auf Repositorys in YAML-Pipelines schützen

Autorisierungsbereich für Auftrag auf aktuelles Projekt begrenzen

Azure Pipelines bietet zwei Einstellungen unter Autorisierungsbereich für Auftrag auf aktuelles Projekt begrenzen:

• Autorisierungsbereich für Auftrag für Nicht-Releasepipelines auf aktuelles Projekt begrenzen: Diese Einstellung gilt für YAML-Pipelines und klassische Buildpipelines. Sie gilt nicht für klassische Releasepipelines.
• Autorisierungsbereich für Auftrag für Releasepipelines auf aktuelles Projekt begrenzen: Diese Einstellung gilt nur für klassische Releasepipelines.

Pipelines werden mit sammlungsbezogenen Zugriffstoken ausgeführt, sofern die entsprechende Einstellung für den Pipelinetyp nicht aktiviert ist. Mit den Einstellungen zum Begrenzen des Auftragsautorisierungsbereichs können Sie den Zugriffsbereich für alle Pipelines auf das aktuelle Projekt beschränken. Dies kann sich auf Ihre Pipeline auswirken, wenn Sie auf ein Azure Repos-Git-Repository in einem anderen Projekt in Ihrer Organisation zugreifen.

Wenn sich Ihr Azure Repos-Git-Repository in einem anderen Projekt als Ihre Pipeline befindet und die Einstellung zum Begrenzen des Auftragsautorisierungsbereichs für Ihren Pipelinetyp aktiviert ist, müssen Sie der Builddienstidentität für Ihre Pipeline die Berechtigung für das zweite Projekt erteilen. Weitere Informationen finden Sie unter Verwalten der Berechtigungen für das Builddienstkonto.

Weitere Informationen zum Begrenzen des Auftragsautorisierungsbereichs finden Sie unter Grundlegendes zu Auftragszugriffstoken.

Zugriff auf Repositorys in YAML-Pipelines schützen

Wie im vorherigen Abschnitt Autorisierungsbereich für Auftrag auf aktuelles Projekt begrenzen beschrieben, können Pipelines auf alle Azure DevOps-Repositorys in autorisierten Projekten zugreifen, sofern Zugriff auf Repositorys in YAML-Pipelines schützen nicht aktiviert ist. Wenn diese Option aktiviert ist, können Sie den Zugriffsbereich für alle Pipelines auf die Azure DevOps-Repositorys beschränken, auf die explizit in einem checkout-Schritt oder einer uses-Anweisung im Pipelineauftrag verwiesen wird, der dieses Repository verwendet.

Navigieren Sie zum Konfigurieren dieser Einstellung unter Organisationseinstellungen oder Projekteinstellungen zu Pipelines > Einstellungen. Wenn die Einstellung auf der Organisationsebene aktiviert ist, ist sie auf der Projekteinstellungsebene ausgegraut und nicht verfügbar.

Wichtig

Die Option Zugriff auf Repositorys in YAML-Pipelines schützen ist standardmäßig für neue Organisationen und Projekte aktiviert, die nach Mai 2020 erstellt wurden. Wenn Zugriff auf Repositorys in YAML-Pipelines schützen aktiviert ist, müssen Ihre YAML-Pipelines explizit auf alle Azure Repos-Git-Repositorys verweisen, die Sie in der Pipeline als Check-Out-Schritt im Auftrag mit dem Repository verwenden möchten. Sie können Code nicht mithilfe von Skriptaufgaben und Git-Befehlen für ein Azure Repos-Git-Repository abrufen, es sei denn, es wird zuerst explizit auf dieses Repository verwiesen.

Es gibt einige Ausnahmefälle, in denen Sie nicht explizit auf ein Azure Repos-Git-Repository verweisen müssen, bevor Sie es in Ihrer Pipeline verwenden, wenn Zugriff auf Repositorys in YAML-Pipelines schützen aktiviert ist.

• Wenn Ihre Pipeline keinen expliziten Check-Out-Schritt enthält, ist es so, als hätten Sie einen checkout: self-Schritt, und das self-Repository wird ausgecheckt.
• Wenn Sie ein Skript verwenden, um schreibgeschützte Vorgänge für ein Repository in einem öffentlichen Projekt auszuführen, müssen Sie nicht in einem checkout-Schritt auf das öffentliche Projektrepository verweisen.
• Wenn Sie ein Skript verwenden, das eine eigene Authentifizierung für das Repository bereitstellt (z. B. ein persönliches Zugriffstoken), müssen Sie nicht in einem checkout-Schritt auf dieses Repository verweisen.

Wenn beispielsweise Zugriff auf Repositorys in YAML-Pipelines schützen aktiviert ist, Ihre Pipeline sich im Repository FabrikamProject/Fabrikam in Ihrer Organisation befindet und Sie ein Skript zum Auschecken des Repositorys FabrikamProject/FabrikamTools verwenden möchten, müssen Sie entweder in einem checkout-Schritt oder mit einer uses-Anweisung auf dieses Repository verweisen.

Wenn Sie das Repository FabrikamTools in Ihrer Pipeline bereits mit einem Check-Out-Schritt auschecken, können Sie anschließend mithilfe von Skripts mit diesem Repository interagieren.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Hinweis

In vielen Szenarien kann die Funktion zum Auschecken mehrerer Repositorys genutzt werden, wodurch die Notwendigkeit entfällt, Skripts zum Auschecken zusätzlicher Repositorys in Ihrer Pipeline zu verwenden. Weitere Informationen finden Sie im Artikel zum Auschecken mehrerer Repositorys in Ihrer Pipeline.

Auschecken

Wenn eine Pipeline ausgelöst wird, pullt Azure Pipelines Ihren Quellcode aus dem Azure Repos-Git-Repository. Sie können verschiedene Aspekte dieses Vorgangs steuern.

Hinweis

Wenn Sie einen Check-Out-Schritt in Ihre Pipeline einschließen, wird der folgende Befehl ausgeführt: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Falls dies nicht Ihren Anforderungen entspricht, können Sie den integrierten Check-Out durch Angabe von checkout: none ausschließen und dann eine Skriptaufgabe verwenden, um Ihren eigenen Check-Out-Vorgang durchzuführen.

Bevorzugte Git-Version

Der Windows-Agent verfügt über eine eigene Git-Version. Wenn Sie Ihre eigene Git-Version bereitstellen möchten, anstatt die enthaltene Version zu verwenden, legen Sie System.PreferGitFromPath auf true fest. Diese Einstellung ist bei Nicht-Windows-Agents immer auf „true“ festgelegt.

Check-Out-Pfad

YAML

Wenn Sie ein einzelnes Repository auschecken, wird Ihr Quellcode standardmäßig in ein Verzeichnis namens s ausgecheckt. Für YAML-Pipelines können Sie dies ändern, indem Sie checkout mit einem path-Wert angeben. Der angegebene Pfad ist relativ zu $(Agent.BuildDirectory). Beispiel: Wenn der Wert für den Check-Out-Pfad mycustompath lautet und $(Agent.BuildDirectory) auf C:\agent\_work\1 festgelegt ist, wird der Quellcode in C:\agent\_work\1\mycustompath ausgecheckt.

Wenn Sie mehrere checkout-Schritte verwenden, mehrere Repositorys auschecken und den Ordner nicht explizit mit path angeben, wird jedes Repository in einem Unterordner von s abgelegt, der nach dem Repository benannt ist. Wenn Sie zum Beispiel zwei Repositorys mit den Namen tools und code auschecken, wird der Quellcode in C:\agent\_work\1\s\tools und C:\agent\_work\1\s\code ausgecheckt.

Beachten Sie, dass der Wert für den Check-Out-Pfad nicht auf Verzeichnisebenen oberhalb von $(Agent.BuildDirectory) festgelegt werden kann. Daher führt die Angabe von path\..\anotherpath zu einem gültigen Check-Out-Pfad (d. h. C:\agent\_work\1\anotherpath), die Angabe von ..\invalidpath jedoch nicht (d. h. C:\agent\_work\invalidpath).

Sie können die path-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

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

Klassisch

Diese Einstellung kann im klassischen Editor nicht konfiguriert werden. Ihr Quellcode wird in ein Verzeichnis namens s ausgecheckt, das relativ zu $(Agent.BuildDirectory) ist. Beispiel: Wenn $(Agent.BuildDirectory) auf C:\agent\_work\1 festgelegt ist, wird der Quellcode in C:\agent\_work\1\mycustompathausgecheckt.

Submodule

YAML

Sie können die Einstellung submodules im Check-Out-Schritt Ihrer Pipeline konfigurieren, wenn Sie Dateien aus Submodulen herunterladen möchten.

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

Klassisch

Sie können die Einstellung Submodule in den Einstellungen der Aufgabe Quellen abrufen Ihrer Pipeline konfigurieren, wenn Sie Dateien aus Submodulen herunterladen möchten.

Die Buildpipeline checkt Ihre Git-Submodule aus, sofern Folgendes auf sie zutrifft:

• Nicht authentifiziert: Ein öffentliches, nicht authentifiziertes Repository, für das keine Anmeldeinformationen zum Klonen oder Abrufen erforderlich sind.

• Authentifiziert:

  • Ist im selben Projekt enthalten wie das oben angegebene Azure Repos-Git-Repository. Die Anmeldeinformationen, die der Agent zum Abrufen der Quellen aus dem Hauptrepository verwendet, werden auch zum Abrufen der Quellen für Submodule verwendet.

  • Wird mithilfe einer URL relativ zum Hauptrepository hinzugefügt. Beispiel:

    • Folgendes Submodul würde ausgecheckt: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      In diesem Beispiel verweist das Submodul auf ein Repository (FabrikamFiber) in derselben Azure DevOps-Organisation, aber in einem anderen Projekt (FabrikamFiberProject). Die Anmeldeinformationen, die der Agent zum Abrufen der Quellen aus dem Hauptrepository verwendet, werden auch zum Abrufen der Quellen für Submodule verwendet. Dies setzt voraus, dass das Auftragszugriffstoken Zugriff auf das Repository im zweiten Projekt hat. Wenn Sie das Auftragszugriffstoken wie im obigen Abschnitt erläutert eingeschränkt haben, ist dies nicht möglich. Sie können dem Auftragszugriffstoken den Zugriff auf das Repository im zweiten Projekt erlauben, indem Sie entweder (a) explizit Zugriff auf das Konto des Projektbuilddiensts im zweiten Projekt gewähren oder (b) sammlungsbezogene Zugriffstoken anstelle projektbezogener Token für die gesamte Organisation verwenden. Weitere Informationen zu diesen Optionen und ihren Auswirkungen auf die Sicherheit finden Sie unter Zugreifen auf Repositorys, Artefakte und andere Ressourcen.

    • Folgendes Submodul würde nicht ausgecheckt: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternative zur Verwendung der Option „Submodule auschecken“

In einigen Fällen kann die Option Submodule auschecken nicht verwendet werden. Möglicherweise liegt ein Szenario vor, in dem für den Zugriff auf die Submodule andere Anmeldeinformationen benötigt werden. Dies kann beispielsweise der Fall sein, wenn Ihr Hauptrepository und die Repositorys der Submodule nicht in derselben Azure DevOps-Organisation gespeichert sind oder Ihr Auftragszugriffstoken keinen Zugriff auf das Repository in einem anderen Projekt hat.

Wenn die Option Submodule auschecken nicht verwendet werden kann, können Sie stattdessen einen benutzerdefinierten Skriptschritt zum Abrufen von Submodulen verwenden. Rufen Sie zunächst ein persönliches Zugriffstoken (Personal Access Token, PAT) ab, und stellen Sie ihm pat: voran. Als Nächstes codieren Sie diese mit einem Präfix versehene Zeichenfolge mit Base64, um ein Standardauthentifizierungstoken zu erstellen. Abschließend fügen Sie Ihrer Pipeline dieses Skript hinzu:

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

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

Verwenden Sie eine Geheimnisvariable in Ihrem Projekt oder Ihrer Buildpipeline, um das von Ihnen generierte Standardauthentifizierungstoken speichern. Verwenden Sie diese Variable, um das Geheimnis im obigen Git-Befehl aufzufüllen.

Hinweis

F: Warum kann ich keine Git-Anmeldeinformationsverwaltung für den Agent verwenden? A: Es ist in der Regel nicht effizient, die Anmeldeinformationen für Submodule in einer Git-Anmeldeinformationsverwaltung zu speichern, die auf Ihrem privaten Build-Agent installiert ist, da Sie möglicherweise bei jeder Aktualisierung des Submoduls zur erneuten Eingabe der Anmeldeinformationen aufgefordert werden. Dies ist bei automatisierten Builds nicht wünschenswert, wenn keine Interaktion mit den Benutzer*innen möglich ist.

Synchronisieren von Tags

Wichtig

Das Feature für Synchronisierungstags wird in Azure Repos Git mit Azure DevOps Server 2022.1 und höher unterstützt.

Im Check-Out-Schritt wird die Option --tags beim Abrufen des Inhalts eines Git-Repositorys verwendet. Dies bewirkt, dass der Server alle Tags und alle Objekte abruft, auf die von diesen Tags verwiesen wird. Dadurch verlängert sich die Ausführungsdauer der Aufgabe in einer Pipeline, insbesondere wenn es sich um ein umfangreiches Repository mit vielen Tags handelt. Darüber hinaus synchronisiert der Check-Out-Schritt Tags, auch wenn Sie die Option für flaches Abrufen aktivieren, was dem eigentlichen Zweck dieser Option widerspricht. Um die Menge der Daten zu reduzieren, die aus einem Git-Repository abgerufen oder gepullt werden, hat Microsoft eine neue Check-Out-Option hinzugefügt, mit der das Verhalten bei der Synchronisierung von Tags gesteuert werden kann. Diese Option ist sowohl in klassischen als auch in YAML-Pipelines verfügbar.

Ob Tags beim Auschecken eines Repositorys synchronisiert werden, können Sie in YAML durch Festlegen der fetchTags-Eigenschaft und in der Benutzeroberfläche durch Festlegen der Einstellung Tags synchronisieren konfigurieren.

YAML

Sie können die fetchTags-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

In YAML legen Sie zum Konfigurieren der Einstellung die fetchTags-Eigenschaft fest.

steps:
- checkout: self
  fetchTags: true

Sie können diese Einstellung auch mit der Option Tags synchronisieren in der Benutzeroberfläche für die Pipelineeinstellungen konfigurieren.

1. Bearbeiten Sie Ihre YAML-Pipeline, und wählen Sie Weitere Aktionen > Trigger aus.

   

2. Wählen Sie YAML und dann Quellen abrufen aus.

   

3. Konfigurieren Sie die Einstellung Tags synchronisieren.

   

Hinweis

Wenn Sie fetchTags in Ihrem checkout-Schritt explizit festlegen, hat diese Einstellung Vorrang vor der Einstellung, die in der Benutzeroberfläche mit den Pipelineeinstellungen konfiguriert ist.

Klassisch

Sie können die Einstellung Tags synchronisieren in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline konfigurieren.

Standardverhalten

• Für vorhandene Pipelines, die vor dem Release von Azure DevOps Sprint 209 vom September 2022 erstellt wurden, bleibt das Standardverhalten für die Synchronisierung von Tags unverändert und entspricht weiterhin dem Verhalten vor dem Hinzufügen der Optionen für Tags synchronisieren (d. h. true).
• Für neue Pipelines, die nach dem Release von Azure DevOps-Sprint 209 erstellt wurden, ist false der Standardwert für die Synchronisierung von Tags.

Hinweis

Wenn Sie fetchTags in Ihrem checkout-Schritt explizit festlegen, hat diese Einstellung Vorrang vor der Einstellung, die in der Benutzeroberfläche mit den Pipelineeinstellungen konfiguriert ist.

Flaches Abrufen

Sie können Downloads bei Bedarf auf eine bestimmte Zeitspanne in der Vergangenheit beschränken. Dies führt effektiv zu git fetch --depth=n. Bei einem großen Repository kann diese Option die Effizienz Ihrer Buildpipeline verbessern. Ihr Repository kann groß sein, wenn es schon lange verwendet wird und einen umfangreichen Verlauf aufweist. Das Repository kann auch groß sein, wenn Sie große Dateien hinzugefügt und später gelöscht haben.

Wichtig

Für neue Pipelines, die nach dem Azure DevOps-Sprint 209-Update vom September 2022 erstellt wurden, ist Flaches Abrufen standardmäßig aktiviert und mit der Tiefe 1 konfiguriert. Davor war das flache Abrufen nicht die Standardeinstellung. Um Ihre Pipeline zu überprüfen, sehen Sie sich wie im folgenden Abschnitt beschrieben die Einstellung Flaches Abrufen in der Benutzeroberfläche der Pipelineeinstellungen an.

YAML

Sie können die fetchDepth-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

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

Sie können die Abruftiefe auch konfigurieren, indem Sie die Option Tiefe für flaches Abrufen in der Benutzeroberfläche mit den Pipelineeinstellungen festlegen.

1. Bearbeiten Sie Ihre YAML-Pipeline, und wählen Sie Weitere Aktionen > Trigger aus.

   

2. Wählen Sie YAML und dann Quellen abrufen aus.

   

3. Konfigurieren Sie die Einstellung Flaches Abrufen. Deaktivieren Sie Flaches Abrufen, um das flache Abrufen zu deaktivieren, oder aktivieren Sie das Kontrollkästchen, und geben Sie eine Tiefe ein, um das flache Abrufen zu aktivieren.

   

Hinweis

Wenn Sie fetchDepth in Ihrem checkout-Schritt explizit festlegen, hat diese Einstellung Vorrang vor der Einstellung, die in der Benutzeroberfläche mit den Pipelineeinstellungen konfiguriert ist. Die Einstellung fetchDepth: 0 ruft den gesamten Verlauf ab und überschreibt die Einstellung Flaches Abrufen.

Klassisch

Sie können die Einstellung Flaches Abrufen in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline konfigurieren.

In diesen Fällen hilft diese Option Ihnen dabei, Netzwerk- und Speicherressourcen zu schonen. Gleichzeitig können Sie möglicherweise Zeit sparen. Eine Zeitersparnis ist nicht immer möglich, weil der Server in einigen Situationen Zeit benötigt, um die herunterzuladenden Commits für die von Ihnen angegebene Tiefe zu berechnen.

Hinweis

Beim Starten der Pipeline wird der zu erstellende Branch in eine Commit-ID aufgelöst. Anschließend ruft der Agent den Branch ab und checkt den gewünschten Commit aus. Es gibt ein kleines Zeitfenster zwischen der Auflösung eines Branchs in eine Commit-ID und dem Zeitpunkt, an dem der Agent den Check-Out durchführt. Wenn der Branch umgehend aktualisiert wird und Sie einen sehr kleinen Wert für „Flaches Abrufen“ festlegen, ist der Commit möglicherweise nicht vorhanden, wenn der Agent versucht, ihn auszuchecken. Erhöhen Sie in diesem Fall die Einstellung der Tiefe für das „Flaches Abrufen“.

Keine Synchronisierung von Quellen

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

• Git-Initialisierung, -Konfiguration und -Abruf mit Ihren eigenen, benutzerdefinierten Optionen

• Verwenden einer Buildpipeline, um nur Automatisierungen (z. B. einige Skripts) auszuführen, die keinen Code in der Versionskontrolle benötigen

YAML

Sie können die Einstellung Quellen nicht synchronisieren im Check-Out-Schritt Ihrer Pipeline konfigurieren, indem Sie checkout: none festlegen.

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

Klassisch

Wählen Sie in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline die Einstellung Quellen nicht synchronisieren aus.

Hinweis

Wenn Sie diese Option verwenden, überspringt der Agent auch die Ausführung von Git-Befehlen, die das Repository bereinigen.

Bereinigen von Builds

Es gibt verschiedene Möglichkeiten zum Bereinigen des Arbeitsverzeichnisses Ihres selbstgehosteten Agents, bevor ein Build ausgeführt wird.

Im Allgemeinen sollten Sie das Repository nicht bereinigen, um die Leistung Ihrer selbstgehosteten Agents zu erhöhen. Um die beste Leistung zu erzielen, sollten Sie in diesem Fall auch sicherstellen, dass die Erstellung inkrementell erfolgt. Deaktivieren Sie dazu die Option Bereinigen der Aufgabe oder des Tools, die bzw. das Sie zur Builderstellung verwenden.

Wenn Sie das Repository bereinigen müssen (z. B. um Probleme zu vermeiden, die durch verbleibende Dateien aus einem früheren Build verursacht werden), haben Sie folgende Möglichkeiten.

Hinweis

Die Bereinigung ist nicht effizient, wenn Sie einen von Microsoft gehosteten Agent verwenden, da jedes Mal ein neuer Agent abgerufen wird.

YAML

Sie können die clean-Einstellung im Check-Out-Schritt Ihrer Pipeline konfigurieren.

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

Wenn clean auf true festgelegt ist, macht die Buildpipeline alle Änderungen in $(Build.SourcesDirectory) rückgängig. Insbesondere werden die folgenden Git-Befehle ausgeführt, bevor der Quellcode abgerufen wird.

git clean -ffdx
git reset --hard HEAD

Weitere Möglichkeiten bietet die Konfiguration der workspace-Einstellung eines Auftrags.

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

Dort erhalten Sie die folgenden Optionen zum Bereinigen.

• outputs: Dies ist der gleiche Vorgang wie bei der Einstellung „clean“ in der oben beschriebenen Check-Out-Aufgabe, zusätzlich wird $(Build.BinariesDirectory) gelöscht und neu erstellt. Beachten Sie, dass $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) unabhängig von diesen Einstellungen immer gelöscht und vor jedem Build neu erstellt werden.

• resources: Löscht $(Build.SourcesDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

• all: Löscht $(Agent.BuildDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

Klassisch

Wählen Sie in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline die Einstellung Bereinigen und dann eine der folgenden Optionen aus.

• Quellen: Die Buildpipeline macht alle Änderungen in $(Build.SourcesDirectory) rückgängig. Insbesondere werden die folgenden Git-Befehle ausgeführt, bevor der Quellcode abgerufen wird.

  git clean -ffdx
  git reset --hard HEAD
  

• Quellen und Ausgabeverzeichnis: Dies ist der gleiche Vorgang wie bei der oben beschriebenen Option Quellen, zusätzlich wird $(Build.BinariesDirectory) gelöscht und neu erstellt. Beachten Sie, dass $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) unabhängig von diesen Einstellungen immer gelöscht und vor jedem Build neu erstellt werden.

• Quellenverzeichnis: Löscht $(Build.SourcesDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

• Alle Buildverzeichnisse: Löscht $(Agent.BuildDirectory) und erstellt es neu. Das führt dazu, dass für jeden Build ein neues, lokales Git-Repository initialisiert wird.

Bezeichnen von Quellen

Vielleicht möchten Sie Ihre Quellcodedateien mit Bezeichnungen versehen, damit Ihr Team leicht erkennen kann, welche Version der jeweiligen Dateien im fertigen Build enthalten ist. Sie können außerdem festlegen, ob der Quellcode für alle Builds oder nur für erfolgreiche Builds mit Bezeichnungen versehen werden soll.

YAML

Sie können diese Einstellung derzeit im klassischen Editor konfigurieren, nicht aber in YAML. Wenn Sie eine YAML-Pipeline bearbeiten, können Sie auf den klassischen Editor zugreifen, indem Sie im Menü des YAML-Editors einen Trigger auswählen.

Wählen Sie im klassischen Editor YAML und dann die Aufgabe Quellen abrufen aus, und konfigurieren Sie anschließend die gewünschten Eigenschaften.

Klassisch

Sie können die Einstellung Tagquellen in den Eigenschaften der Aufgabe Quellen abrufen in Ihrer Pipeline konfigurieren.

Im Tagformat können Sie benutzerdefinierte und vordefinierte Variablen mit dem Bereich „Alle“ verwenden. Ein Beispiel:

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

Die ersten vier Variablen sind vordefiniert. My.Variable kann von Ihnen auf der Registerkarte „Variablen“ definiert werden.

Die Buildpipeline versieht Ihre Quellen mit einem Git-Tag.

Einige Buildvariablen können einen Wert ergeben, der keine gültige Bezeichnung ist. Beispielsweise können Variablen wie $(Build.RequestedFor) und $(Build.DefinitionName) Leerzeichen enthalten. Wenn der Wert Leerzeichen enthält, wird das Tag nicht erstellt.

Nachdem die Quellen von Ihrer Buildpipeline mit einer Bezeichnung versehen wurden, wird dem fertigen Build automatisch ein Artefakt mit dem Git-Verweis refs/tags/{tag} hinzugefügt. Das bietet Ihrem Team zusätzliche Nachvollziehbarkeit und eine benutzerfreundlichere Möglichkeit, vom Build zum kompilierten Code zu navigieren. Das Tag wird als Buildartefakt betrachtet, da es durch den Build erzeugt wird. Wird der Build entweder manuell oder über eine Aufbewahrungsrichtlinie gelöscht, wird auch das Tag gelöscht.

Häufig gestellte Fragen

Probleme im Zusammenhang mit der Azure Repos-Integration lassen sich in drei Kategorien unterteilen:

• Triggerfehler: Meine Pipeline wird nicht ausgelöst, wenn ich eine Aktualisierung an das Repository pushe.
• Fehler beim Auschecken: Meine Pipeline wird ausgelöst, aber sie schlägt im Auscheckschritt fehl.
• 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.

  

• Konfigurieren Sie den PR-Trigger in der YAML-Datei oder in Branchrichtlinien für das Repository? Für ein Azure Repos-Git-Repository können Sie keinen PR-Trigger in der YAML-Datei konfigurieren. Sie müssen Branchrichtlinien verwenden.

• Ist Ihre Pipeline angehalten oder deaktiviert? Öffnen Sie den Editor für die Pipeline, und wählen Sie Einstellungen aus, um dies zu überprüfen. Wenn Ihre Pipeline angehalten oder deaktiviert ist, funktionieren Trigger nicht.

• Haben Sie die YAML-Datei im richtigen Branch aktualisiert? Wenn Sie eine Aktualisierung an einen Branch pushen, steuert die YAML-Datei in diesem Branch das CI-Verhalten. Wenn Sie eine Aktualisierung an einen Quellbranch pushen, steuert die YAML-Datei, die sich aus dem Mergen des Quellbranchs mit dem Zielbranch ergibt, das PR-Verhalten. Stellen Sie sicher, dass die YAML-Datei im richtigen Branch über die erforderliche CI- oder PR-Konfiguration verfügt.

• Haben Sie den Trigger richtig konfiguriert? Wenn Sie einen YAML-Trigger definieren, können Sie sowohl Einschluss- als auch Ausschlussklauseln für Branches, Tags und Pfade angeben. Vergewissern Sie sich, dass die Einschlussklausel mit den Details Ihres Commits übereinstimmt und dass die Ausschlussklausel diese nicht ausschließt. Überprüfen Sie die Syntax für die Trigger, und stellen Sie sicher, dass sie korrekt ist.

• Haben Sie bei der Definition des Triggers oder der Pfade Variablen verwendet? Dies wird nicht unterstützt.

• Haben Sie Vorlagen für Ihre YAML-Datei verwendet? Wenn ja, stellen Sie sicher, dass Ihre Trigger in der YAML-Hauptdatei definiert sind. In Vorlagendateien definierte Trigger werden nicht unterstützt.

• Haben Sie die Branches oder Pfade ausgeschlossen, an die Sie Ihre Änderungen gepusht haben? Testen Sie dies, indem Sie eine Änderung an einen eingeschlossenen Pfad in einem eingeschlossenen Branch pushen. Denken Sie daran, dass bei Pfaden in Triggern die Groß-/Kleinschreibung beachtet wird. Stellen Sie sicher, dass Sie beim Angeben der Pfade in Triggern dieselbe Groß-/Kleinschreibung verwenden wie bei den tatsächlichen Ordnern.

• Haben Sie gerade einen neuen Branch gepusht? Wenn ja, startet der neue Branch möglicherweise keine neue Ausführung. Weitere Informationen finden Sie im Abschnitt „Verhalten von Triggern beim Erstellen neuer Branches“.

Meine CI- oder PR-Trigger haben einwandfrei funktioniert. Aber jetzt funktionieren sie nicht mehr.

Führen Sie zunächst die Schritte zur Problembehandlung in der vorherigen Frage durch. 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.

Ich habe mehrere Repositorys in meiner YAML-Pipeline. Wie richte ich Trigger für jedes Repository ein?

Lesen Sie den Abschnitt „Trigger“ unter Verwenden mehrerer Repositorys.

Fehler beim Check-Out

Im Check-Out-Schritt wird der folgende Fehler in der Protokolldatei angezeigt. Wie behebe ich das Problem?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Führen Sie die folgenden Schritte aus, um Fehler beim Check-Out zu beheben:

• Ist das Repository noch vorhanden? Stellen Sie zunächst sicher, dass dies der Fall ist, indem Sie das Repository auf der Seite Repositorys öffnen.

• Greifen Sie mithilfe eines Skripts auf das Repository zu? Wenn ja, überprüfen Sie die Einstellung Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken. Wenn Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken aktiviert ist, können Sie Azure Repos-Git-Repositorys nur dann mithilfe eines Skripts auschecken, wenn zuerst in der Pipeline explizit auf sie verwiesen wird.

• Wie lautet der Auftragsautorisierungsbereich der Pipeline?

  • Beim Bereich Sammlung:

    • Dies kann ein zeitweiliger Fehler sein. Führen Sie die Pipeline erneut aus.
    • Möglicherweise hat jemand den Zugriff auf das Builddienstkonto für die Projektsammlung entfernt.
      • Wechseln Sie für das Projekt, in dem sich das Repository befindet, zu Projekteinstellungen. Wählen Sie Repositorys > Repositorys > jeweiliges Repository und dann Sicherheit aus.
      • Überprüfen Sie, ob Builddienst für Projektsammlung (Name Ihrer Sammlung) in der Liste der Benutzer*innen aufgeführt ist.
      • Überprüfen Sie, ob dieses Konto über die Zugriffsrechte Tag erstellen und Lesen verfügt.

  • Beim Bereich Projekt:

    • Befindet sich das Repository im selben Projekt wie die Pipeline?
      • Ja:
        • Dies kann ein zeitweiliger Fehler sein. Führen Sie die Pipeline erneut aus.
        • Möglicherweise hat jemand den Zugriff auf das Builddienstkonto für das Projekt entfernt.
          • Wechseln Sie für das Projekt, in dem sich das Repository befindet, zu Projekteinstellungen. Wählen Sie Repositorys > Repositorys > jeweiliges Repository und dann Sicherheit aus.
          • Überprüfen Sie, ob Name Ihres Projekts – Builddienst (Name Ihrer Sammlung) in der Liste der Benutzer*innen aufgeführt ist.
          • Überprüfen Sie, ob dieses Konto über die Zugriffsrechte Tag erstellen und Lesen verfügt.
      • Nein:
        • Befindet sich Ihre Pipeline in einem öffentlichen Projekt?
          • Ja: Sie können nicht auf Ressourcen außerhalb des öffentlichen Projekts zugreifen. Legen Sie das Projekt als privat fest.
          • Nein: Sie müssen Berechtigungen für den Zugriff auf ein anderes Repository in derselben Projektsammlung konfigurieren.

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 Mergen der Quell- und Zielbranches des Pull Requests ergibt, ausgewertet, um festzustellen, ob ein PR-Build ausgeführt werden soll.

Verwandte Artikel

• Geplante Trigger
• Pipelineabschlusstrigger