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

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 ***NO_CI*** in die Nachricht der Commits ein, die Teil eines Pushs sind, und Azure Pipelines überspringt die Ausführung von CI für diesen Push.

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***

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

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

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

Pipelines werden mit sammlungsbezogenen Zugriffstoken ausgeführt, es sei denn Autorisierungsbereich für Auftrag auf aktuelles Projekt begrenzen ist aktiviert. Mit dieser Einstellung 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 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 Auftragsautorisierungsbereich.

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

Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken

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 Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken 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.

Wenn Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken 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 Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken 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 Auftragsautorisierungsbereich auf referenzierte Azure DevOps-Repositorys einschränken 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

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.

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

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.

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

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

Submodule

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Die Buildpipeline checkt Ihre Git-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.

Synchronisieren von Tags

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.

steps:
- checkout: self
  fetchTags: true

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.

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.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

In diesen Fällen 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.

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

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

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.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

git clean -ffdx
git reset --hard HEAD

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

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.

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.