Pipelineoptionen für Git-Repositorys

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

Beim Bearbeiten einer Pipeline, die ein Git-Repository verwendet – in einem Azure DevOps-Projekt, einem GitHub-, GitHub Enterprise Server-, Bitbucket Cloud- oder einem anderen Git-Repository – stehen Ihnen die folgenden Optionen zur Verfügung.

Verzweigung

Dies ist der Branch, den Sie als Standardbranch verwenden möchten, wenn Sie diesen Build manuell in die Warteschlange einreihen. Wenn Sie einen geplanten Trigger für den Build festlegen, ist dies der Branch, aus dem Ihr Build die neuesten Quellen abruft. Der Standardbranch hat keinerlei Auswirkungen, wenn der Build per Continuous Integration (CI) ausgelöst wird. Üblicherweise legen Sie diesen Wert auf den Standardbranch des Repositorys (z. B. „master“) fest.

Bereinigen des lokalen Repositorys für den Agent

Sie können das Arbeitsverzeichnis Ihres selbstgehosteten Agents auf verschiedene Arten bereinigen, 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.

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: true
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

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 gekennzeichnet werden soll.

In Kennzeichnungsformat 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.

Buildstatus melden (Azure Pipelines, TFS 2018 und höher)

Sie haben die Möglichkeit, Ihrem Team einen Überblick über den Buildstatus in Ihrem Remotequellrepository zu geben.

Wenn sich Ihre Quellen in einem Azure Repos-Git-Repository in Ihrem Projekt befinden, wird mit dieser Option auf der Seite Code ein Badge angezeigt. Dieser zeigt an, ob der Build erfolgreich war oder nicht. Die Buildstatus wird auf den folgenden Registerkarten angezeigt:

• Dateien: Zeigt den Status des letzten Builds für den ausgewählten Branch an.
• Commits: Zeigt den Buildstatus der einzelnen Commits an (hierzu muss der Trigger für Continuous Integration [CI] für Ihre Builds aktiviert sein).
• Branches: Zeigt den Status des letzten Builds für jeden Branch an.

Wenn Sie in Ihrem Projekt mehrere Buildpipelines für dasselbe Repository verwenden, können Sie diese Option für eine oder mehrere der Pipelines aktivieren. Wenn diese Option für mehrere Pipelines aktiviert ist, zeigt der Badge auf der Seite Code den Status des neuesten Builds für alle Pipelines an. Ihre Teammitglieder können auf den Badge für den Buildstatus klicken, um den neuesten Buildstatus für jede einzelne Buildpipeline anzuzeigen.

Andere Arten von Git-Remoterepositorys

Wenn sich Ihre Quelle in einer anderen Art von Remoterepository befindet, können Sie den Buildstatus nicht mit Azure Pipelines oder TFS automatisch in diesem Repository veröffentlichen. Sie können jedoch einen Buildbadge verwenden, um den Buildstatus in Ihre Versionskontrolle zu integrieren und anzuzeigen.

Check-Out von Untermodulen

Geben Sie an, ob Dateien aus Submodulen heruntergeladen werden sollen. Sie können entweder die unmittelbaren Submodule oder alle bis zu einer beliebigen Rekursionstiefe geschachtelten Submodule abrufen. Wenn Sie LFS mit Submodulen verwenden möchten, beachten Sie den Hinweis zur Verwendung von LFS mit Submodulen.

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:

  • Im selben Projekt, derselben GitHub-Organisation oder demselben Bitbucket Cloud-Konto enthalten wie das oben angegebene Git-Repository.

  • Wird mithilfe einer URL relativ zum Hauptrepository hinzugefügt. Dieses Modul wäre beispielsweise ausgecheckt: git submodule add /../../submodule.git mymodule Dieses wäre nicht ausgecheckt: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Authentifizierte Submodule

Dieselben Anmeldeinformationen, die der Agent zum Abrufen der Quellen aus dem Hauptrepository verwendet, werden auch zum Abrufen der Quellen für die Submodule verwendet.

Wenn sich Ihr Hauptrepository und die Submodule in einem Azure Repos-Git-Repository in Ihrem Azure DevOps-Projekt befinden, können Sie das Konto auswählen, das für den Zugriff auf die Quellen verwendet wird. Wählen Sie auf der Registerkarte Optionen im Menü Autorisierungsbereich für Buildauftrag eine der folgenden Optionen aus:

• Projektsammlung zur Verwendung des Builddienstkontos für die Projektsammlung.

• Aktuelles Projekt zur Verwendung des Builddienstkontos für das Projekt.

Stellen Sie sicher, dass das von Ihnen verwendete Konto sowohl auf das Hauptrepository als auch auf die Submodule zugreifen kann.

Wenn sich Ihr Hauptrepository und die Submodule in derselben GitHub-Organisation befinden, wird das in der GitHub-Dienstverbindung gespeicherte Token für den Zugriff auf die Quellen verwendet.

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. Das kann zum Beispiel der Fall sein, wenn Ihr Hauptrepository und die Repositorys der Submodule nicht in derselben Azure DevOps-Organisation oder im selben Git-Dienst gespeichert sind.

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_TOKEN_DESCRIBED_ABOVE>" submodule update --init --recursive

Ersetzen Sie <BASIC_AUTH_TOKEN> durch Ihr Base64-codiertes Token.

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

Dateien aus LFS auschecken

Wählen Sie aus, ob Sie Dateien aus LFS (Large File Storage) herunterladen möchten.

Aktivieren Sie im klassischen Editor das Kontrollkästchen zum Aktivieren dieser Option.

Fügen Sie in einem YAML-Build einen Schritt zum Auschecken hinzu, bei dem lfs auf true festgelegt ist:

steps:
- checkout: self
  lfs: true

Wenn Sie TFS verwenden oder Azure Pipelines mit einem selbstgehosteten Agent nutzen, müssen Sie git-lfs auf dem Agent installieren, damit diese Option funktioniert. Wenn Ihre gehosteten Agents Windows verwenden, sollten Sie mithilfe der Variablen System.PreferGitFromPath sicherstellen, dass die Pipelines die git- und git-lfs-Versionen verwenden, die Sie auf dem Computer installiert haben. Weitere Informationen finden Sie unter Welche Git-Version wird von meinem Agent ausgeführt?

Verwenden von Git-LFS mit Submodulen

Wenn ein Submodul LFS-Dateien enthält, muss Git-LFS vor dem Auschecken von Submodulen konfiguriert werden. Die von Microsoft gehosteten macOS- und Linux-Agents sind entsprechend vorkonfiguriert, Windows-Agents und selbstgehostete macOS-/Linux-Agents möglicherweise nicht.

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Sekundäres Repository klonen

Standardmäßig ist Ihre Pipeline einem Azure Repos-Repository oder einem Repository eines externen Anbieters zugeordnet. Dies ist das Repository, das Builds für Commits und Pull Requests auslösen kann.

Möglicherweise möchten Sie Quellen aus einem zweiten Repository in Ihre Pipeline einbeziehen. Dazu können Sie ein Skript schreiben.

git clone https://github.com/Microsoft/TypeScript.git

Wenn das Repository nicht öffentlich ist, müssen Sie eine Authentifizierung an den Git-Befehl übergeben.

Azure Repos

- script: | 
    git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame

Wenn Sie ein Repository aus einem anderen Projekt klonen möchten, das nicht öffentlich ist, müssen Sie sich als Benutzer*in authentifizieren, der bzw. die Zugriff auf dieses Projekt hat.

Für Azure Repos können Sie ein persönliches Zugriffstoken mit der Berechtigung Code (Lesen) verwenden. Senden Sie dieses als Kennwortfeld in einem Autorisierungsheader des Typs „Basic“ ohne Benutzernamen. (Anders ausgedrückt: Codieren Sie den Wert von :<PAT> mit Base64, einschließlich des Doppelpunkts.)

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

Quellen nicht synchronisieren

Nicht-Bereitstellungsaufträge rufen automatisch Quellen ab. Verwenden Sie diese Option, wenn Sie dieses Verhalten überspringen möchten. Diese Option kann in Folgenden Fällen nützlich sein:

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

• Verwenden Sie eine Buildpipeline, um nur Automatisierungen (z. B. einige Skripts) auszuführen, die nicht vom Code in der Versionskontrolle abhängen.

Wenn Sie das Herunterladen von Quellen deaktivieren möchten:

• Azure Pipelines, TFS 2018 und höher: Klicken Sie auf Erweiterte Einstellungen, und wählen Sie dann Quellen nicht synchronisieren aus.

Flaches Abrufen

Legen Sie fest, ob Sie das Herunterladen auf eine bestimmte Zeitspanne in der Vergangenheit beschränken möchten. 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.

In diesen Fällen können Sie mit dieser Option Netzwerk- und Speicherressourcen und 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.

Nachdem Sie die Option über das Kontrollkästchen aktiviert haben, geben Sie im Feld Tiefe die Anzahl der Commits an.

Bevorzugen von Git gegenüber Pfad

Standardmäßig verwendet der Windows-Agent die Git-Version, die im Lieferumfang der Agentsoftware enthalten ist. Microsoft empfiehlt, die im Lieferumfang des Agents enthaltene Git-Version zu verwenden. Sie haben jedoch verschiedene Möglichkeiten, dieses Standardverhalten außer Kraft zu setzen und die Git-Version zu verwenden, die im Pfad auf dem Agentcomputer installiert ist.

• Legen Sie eine Pipelinevariable mit dem Namen System.PreferGitFromPath in Ihren Pipelines auf true fest.
• Auf selbstgehosteten Agents können Sie eine ENV-Datei im Stammverzeichnis des Agents erstellen und der Datei die Zeile System.PreferGitFromPath=true hinzufügen. Weitere Informationen finden Sie unter Wie lege ich verschiedene Umgebungsvariablen für jeden einzelnen Agent fest?.

Um die von einer Pipeline verwendete Git-Version zu ermitteln, können Sie sich die Protokolle für einen checkout-Schritt in Ihrer Pipeline ansehen, wie im folgenden Beispiel gezeigt.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Diese Einstellung ist bei Nicht-Windows-Agents immer auf TRUE festgelegt.

Triggeroptionen für andere Git-Repositorys

Wenn ein anderes/externes Git-Repository angegeben wird, erfordern CI-Builds, dass über das Internet auf das Repository zugegriffen werden kann. Wenn sich das Repository hinter einer Firewall oder einem Proxy befindet, funktionieren nur geplante und manuelle Builds.

Häufig gestellte Fragen

Welche Protokolle kann der Build-Agent mit Git verwenden?

Der Agent unterstützt HTTPS.

Der Agent bietet noch keine Unterstützung für SSH. Siehe Zulassen der SSH-Authentifizierung während des Auscheckens von Git-Submodulen bei der Builderstellung.