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.

Funktion	Azure Pipelines	Azure DevOps Server 2019 und höher	TFS 2018
Verzweigung	Ja	Ja	Ja
Clean	Ja	Ja	Ja
Tag- oder Kennzeichnungsquellen	Projekt, nur klassisch	Teamprojekt	Teamprojekt
Buildstatus melden	Ja	Ja	Ja
Submodule auschecken	Ja	Ja	Ja
Dateien aus LFS auschecken	Ja	Ja	Ja
Sekundäres Repository klonen	Ja	Ja	Ja
Quellen nicht synchronisieren	Ja	Ja	Ja
Flaches Abrufen	Ja	Ja	Ja

Hinweis

Klicken Sie in der Aufgabe Quellen abrufen auf die Option Erweiterte Einstellungen, um einige der oben genannten Optionen anzuzeigen.

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.

Hinweis

Die Bereinigung ist nicht effizient, wenn Sie einen von Microsoft gehosteten Agent verwenden, da jedes Mal ein neuer Agent abgerufen wird. Wenn Sie selbstgehostete Agents verwenden, wird je nach Konfiguration Ihrer Agentpools für nachfolgende Pipelineausführungen (oder Phasen oder Aufträge in derselben Pipeline) möglicherweise ein neuer Agent abgerufen. Keine Bereinigung ist also keine Garantie dafür, dass nachfolgende Ausführungen, Aufträge oder Phasen auf die Ausgaben vorheriger Ausführungen, Aufträge oder Stages zugreifen können.

YAML

Azure Pipelines, Azure DevOps Server 2019 und höher

Für YAML-Pipelines stehen verschiedene Bereinigungsoptionen zur Verfügung.

• Der checkout-Schritt umfasst eine clean-Option. Bei einer Festlegung auf true führt die Pipeline execute git clean -ffdx && git reset --hard HEAD aus, bevor das Repository abgerufen wird. Weitere Informationen finden Sie unter Auschecken.
• Die Einstellung workspace für job bietet mehrere Bereinigungsoptionen („outputs“, „resources“, „all“) Weitere Informationen finden Sie unter Arbeitsbereich.
• Die Benutzeroberfläche für Pipelineeinstellungen umfasst eine Einstellung Bereinigen, die bei Festlegung auf „true“ der Angabe von clean: true für jeden checkout-Schritt in Ihrer Pipeline entspricht. So konfigurieren Sie die Einstellung Bereinigen

  1. Bearbeiten Sie Ihre Pipeline, wählen Sie ... und dann Trigger aus.

     

  2. Wählen Sie YAML und dann Quellen abrufen aus, und konfigurieren Sie die gewünschte Einstellung für Bereinigen. Der Standardwert ist true.

     

Zum Überschreiben der Bereinigungseinstellungen bei der manuellen Ausführung einer Pipeline können Sie Laufzeitparameter verwenden. Im folgenden Beispiel wird ein Laufzeitparameter verwendet, um die Einstellung zur Bereinigung beim Auschecken zu konfigurieren.

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

Standardmäßig ist clean auf true festgelegt, kann aber bei einer manuellen Ausführung der Pipeline außer Kraft gesetzt werden, indem Sie das Kontrollkästchen zur Bereinigung beim Auschecken deaktivieren, das für den Laufzeitparameter hinzugefügt wird.

Klassisch

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

Wählen Sie 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 gekennzeichnet werden soll.

Hinweis

Sie können dieses Feature nur verwenden, wenn das Quellrepository in Ihrem Build ein GitHub-Repository oder ein Git- oder TFVC-Repository aus Ihrem Projekt ist.

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.

GitHub

Wenn sich Ihre Quellen in GitHub befinden, veröffentlicht diese Option den Status Ihres Builds mithilfe der GitHub-APIs für Prüfungen oder Status auf GitHub. Wenn Ihr Build durch einen Pull Request von GitHub ausgelöst wurde, können Sie den Status auf der GitHub-Seite für Pull Requests einsehen. So können Sie auch Statusrichtlinien innerhalb von GitHub festlegen und Mergevorgänge automatisieren. Wenn Ihr Build per Continuous Integration (CI) ausgelöst wird, können Sie den Buildstatus im Commit oder Branch in GitHub einsehen.

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

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. Deshalb führt path\..\anotherpath zu einem gültigen Check-Out-Pfad führt (d. h. C:\agent\_work\1\anotherpath), der Wert ..\invalidpath jedoch nicht (d. h. C:\agent\_work\invalidpath).

Wenn Sie mehrere checkout-Schritte verwenden, mehrere Repositorys auschecken und den Ordner explizit mit path angeben möchten, sollten Sie keinen Pfad angeben, bei dem es sich um einen Unterordner eines anderen Check-Out-Schritts handelt (z. B. C:\agent\_work\1\s\repo1 und C:\agent\_work\1\s\repo1\repo2), da ansonsten der Unterordner des Check-Out-Schritts durch die Bereinigung eines anderen Repositorys geleert wird. (Beachten Sie, dass dieser Fall gültig ist, wenn die Bereinigungsoption für repo1 auf „true“ festgelegt ist.)

Hinweis

Der Check-Out-Pfad kann nur für YAML-Pipelines angegeben werden. Weitere Informationen finden Sie unter Check-Out in YAML-Schema.

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.

Hinweis

Weitere Informationen zur YAML-Syntax für das Auschecken von Submodulen finden Sie unter „Check-Out“ in YAML-Schema.

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

Hinweis

Stellen Sie sicher, dass Sie Ihre Submodule über HTTPS und nicht über SSH registriert haben.

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.

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.

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.

Als Problemumgehung können Sie bei Verwendung von YAML den folgenden Schritt vor checkout hinzufügen:

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

Sie können mehrere Repositorys im selben Projekt wie Ihre Pipeline klonen, indem Sie mehrere Repositorys auschecken.

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.

Hinweis

Verwenden Sie eine Geheimnisvariable, um Anmeldeinformationen sicher zu speichern.

Geheimnisvariablen werden nicht automatisch als Umgebungsvariablen für Skripts zur Verfügung gestellt. Informationen zur Zuordnung dieser Variablen finden Sie unter Geheimnisvariablen.

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.

Hinweis

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

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.

Hinweis

Beim Einreihen des Builds in die Warteschlange 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 für „Flaches Abrufen“.

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

Tipp

Die unten erwähnte Agent.Source.Git.ShallowFetchDepth-Variable ist ebenso wirksam und setzt die Kontrollkästchen-Steuerelemente außer Kraft. Auf diese Weise können Sie die Einstellung ändern, wenn Sie den Build in die Warteschlange einreihen.

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.