Pipelinealternativ för Git-lagringsplatser

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

När du redigerar en pipeline som använder en Git-lagringsplats – i ett Azure DevOps-projekt, GitHub, GitHub Enterprise Server, Bitbucket Cloud eller en annan Git-lagringsplats – har du följande alternativ.

Funktion	Azure-pipelines	Azure DevOps Server 2019 och senare	TFS 2018
Filial	Ja	Ja	Ja
Rensa	Ja	Ja	Ja
Tagg- eller etikettkällor	Projekt; Endast klassisk	Teamprojekt	Teamprojekt
Rapportversionsstatus	Ja	Ja	Ja
Kolla in undermoduler	Ja	Ja	Ja
Kolla in filer från LFS	Ja	Ja	Ja
Klona en andra lagringsplats	Ja	Ja	Ja
Synkronisera inte källor	Ja	Ja	Ja
Ytlig hämtning	Ja	Ja	Ja

Kommentar

Klicka på Avancerade inställningar i aktiviteten Hämta källor för att se några av alternativen ovan.

Filial

Det här är den gren som du vill ska vara standard när du köar den här versionen manuellt. Om du anger en schemalagd utlösare för bygget är det här den gren som bygget kommer att hämta de senaste källorna från. Standardgrenen har ingen betydelse när bygget utlöses via kontinuerlig integrering (CI). Vanligtvis anger du att detta ska vara samma som standardgrenen för lagringsplatsen (till exempel "master").

Rensa den lokala lagringsplatsen på agenten

Du kan utföra olika former av rensning av arbetskatalogen för din lokalt installerade agent innan en version körs.

I allmänhet ska du inte rensa lagringsplatsen för snabbare prestanda för dina lokalt installerade agenter. I det här fallet bör du se till att du också skapar stegvis för att få bästa möjliga prestanda genom att inaktivera alternativet Rensa för den uppgift eller det verktyg som du använder för att skapa.

Om du behöver rensa lagringsplatsen (till exempel för att undvika problem som orsakas av residualfiler från en tidigare version) finns alternativen nedan.

Kommentar

Rensning är inte effektivt om du använder en Microsoft-värdbaserad agent eftersom du får en ny agent varje gång. När du använder lokalt installerade agenter, beroende på hur dina agentpooler konfigureras, kan du få en ny agent för efterföljande pipelinekörningar (eller faser eller jobb i samma pipeline), så att inte rensa är inte en garanti för att efterföljande körningar, jobb eller steg kommer att kunna komma åt utdata från tidigare körningar, jobb eller faser.

YAML

Azure Pipelines, Azure DevOps Server 2019 och senare

Det finns flera olika rena alternativ för YAML-pipelines.

• Steget checkout har ett clean alternativ. När den är inställd truepå körs execute git clean -ffdx && git reset --hard HEAD pipelinen innan lagringsplatsen hämtas. Mer information finns i Checkout.
• Inställningen workspace för job har flera rena alternativ (utdata, resurser, alla). Mer information finns i Arbetsyta.
• Användargränssnittet för pipelineinställningar har en ren inställning som när den är inställd på true motsvarar att clean: true ange för varje checkout steg i pipelinen. Så här konfigurerar du inställningen Rensa :

  1. Redigera din pipeline, välj ...och välj Utlösare.

     

  2. Välj YAML, Hämta källor och konfigurera önskad clean-inställning . Standardvärdet är sant.

     

Om du vill åsidosätta rensningsinställningar när du kör en pipeline manuellt kan du använda körningsparametrar. I följande exempel används en körningsparameter för att konfigurera inställningen rensa utcheckning.

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

Som standard clean är inställt på true men kan åsidosättas när du kör pipelinen manuellt genom att avmarkera kryssrutan Checkout clean som har lagts till för körningsparametern.

Klassisk

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

Välj ett av följande alternativ:

• Källor: Bygg-pipelinen utför en ångrad ändring i $(Build.SourcesDirectory). Mer specifikt körs följande Git-kommandon innan källan hämtas.

  git clean -ffdx
  git reset --hard HEAD
  

• Källor och utdatakatalog: Samma åtgärd som alternativet Källor ovan, plus: Tar bort och återskapar $(Build.BinariesDirectory). Observera att $(Build.ArtifactStagingDirectory) och $(Common.TestResultsDirectory) alltid tas bort och återskapas före varje bygge oavsett någon av dessa inställningar.

• Källkatalog: Tar bort och återskapar $(Build.SourcesDirectory). Detta resulterar i att en ny lokal Git-lagringsplats initieras för varje version.

• Alla byggkataloger: Tar bort och återskapar $(Agent.BuildDirectory). Detta resulterar i att en ny lokal Git-lagringsplats initieras för varje version.

Etikettkällor

Du kanske vill märka dina källkodsfiler så att ditt team enkelt kan identifiera vilken version av varje fil som ingår i den färdiga versionen. Du kan också ange om källkoden ska märkas för alla versioner eller endast för lyckade versioner.

Kommentar

Du kan bara använda den här funktionen när källlagringsplatsen i din version är en GitHub-lagringsplats eller en Git- eller TFVC-lagringsplats från projektet.

I etikettformatet kan du använda användardefinierade och fördefinierade variabler som har omfånget "Alla". Till exempel:

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

De första fyra variablerna är fördefinierade. My.Variablekan definieras av dig på fliken variabler.

Bygg-pipelinen etiketterar dina källor med en Git-tagg.

Vissa byggvariabler kan ge ett värde som inte är en giltig etikett. Variabler som $(Build.RequestedFor) och $(Build.DefinitionName) kan till exempel innehålla tomt utrymme. Om värdet innehåller tomt utrymme skapas inte taggen.

När källorna har taggats av bygg-pipelinen läggs en artefakt med Git-referensen refs/tags/{tag} automatiskt till i den färdiga versionen. Detta ger ditt team ytterligare spårbarhet och ett mer användarvänligt sätt att navigera från bygget till koden som skapades. Taggen anses vara en byggartefakt eftersom den skapas av bygget. När bygget tas bort manuellt eller via en kvarhållningsprincip tas taggen också bort.

Rapportversionsstatus (Azure Pipelines, TFS 2018 och senare)

Du har möjlighet att ge ditt team en vy över byggstatusen från fjärrkällans lagringsplats.

Om dina källor finns på en Git-lagringsplats för Azure Repos i projektet visar det här alternativet ett märke på sidan Kod som anger om bygget skickas eller misslyckas. Byggstatusen visas på följande flikar:

• Filer: Anger status för den senaste versionen för den valda grenen.
• Incheckningar: Anger byggstatusen för varje incheckning (detta kräver att utlösaren för kontinuerlig integrering (CI) aktiveras för dina versioner).
• Grenar: Anger status för den senaste versionen för varje gren.

Om du använder flera byggpipelines för samma lagringsplats i projektet kan du välja att aktivera det här alternativet för en eller flera pipelines. Om det här alternativet är aktiverat på flera pipelines anger märket på sidan Kod status för den senaste versionen för alla pipelines. Dina teammedlemmar kan klicka på byggstatusmärket för att visa den senaste byggstatusen för var och en av byggpipelines.

GitHub

Om dina källor finns i GitHub publicerar det här alternativet status för din version till GitHub med hjälp av GitHub-kontroller eller status-API:er. Om bygget utlöses från en GitHub-pull-begäran kan du visa statusen på sidan För Pull-begäranden för GitHub. På så sätt kan du också ange statusprinciper i GitHub och automatisera sammanslagningar. Om din version utlöses av kontinuerlig integrering (CI) kan du visa byggstatusen för incheckningen eller grenen i GitHub.

Andra typer av Git-fjärrlagringsplatser

Om källan finns i någon annan typ av fjärrlagringsplats kan du inte använda Azure Pipelines eller TFS för att automatiskt publicera byggstatusen till lagringsplatsen. Du kan dock använda ett byggmärke som ett sätt att integrera och visa byggstatus i dina versionskontrollupplevelser.

Sökväg till utcheckning

Om du checkar ut en enda lagringsplats checkas källkoden som standard ut till en katalog med namnet s. För YAML-pipelines kan du ändra detta genom att checkout ange med en path. Den angivna sökvägen är relativ till $(Agent.BuildDirectory). Till exempel: om värdet för utcheckningssökvägen är mycustompath och $(Agent.BuildDirectory) är C:\agent\_work\1, checkas källkoden ut till C:\agent\_work\1\mycustompath.

Om du använder flera checkout steg och checkar ut flera lagringsplatser och inte uttryckligen anger mappen med , pathplaceras varje lagringsplats i en undermapp s med namnet efter lagringsplatsen. Om du till exempel checkar ut två lagringsplatser med namnet tools och code, checkas källkoden ut till C:\agent\_work\1\s\tools och C:\agent\_work\1\s\code.

Observera att värdet för utcheckningssökvägen inte kan anges för att gå upp några katalognivåer ovanför $(Agent.BuildDirectory), så path\..\anotherpath resulterar i en giltig utcheckningssökväg (d.v.s. C:\agent\_work\1\anotherpath), men ett värde som ..\invalidpath inte gör det (dvs. C:\agent\_work\invalidpath).

Om du använder flera checkout steg och checkar ut flera lagringsplatser och uttryckligen vill ange mappen med kan pathdu undvika att ange sökvägen som är undermapp för ett annat utcheckningsstegs sökväg (dvs. C:\agent\_work\1\s\repo1 och C:\agent\_work\1\s\repo1\repo2), annars rensas undermappen i utcheckningssteget av en annan lagringsplatss rensning. Observera att det här fallet är giltigt om alternativet rensa är sant för repo1)

Kommentar

Utcheckningssökvägen kan bara anges för YAML-pipelines. Mer information finns i Checkout i YAML-schemat.

Se undermoduler

Välj om du vill ladda ned filer från undermoduler. Du kan antingen välja att hämta de omedelbara undermodulerna eller alla undermoduler kapslade till ett rekursionsdjup. Om du vill använda LFS med undermoduler ska du se anteckningen om hur du använder LFS med undermoduler.

Kommentar

Mer information om YAML-syntaxen för att checka ut undermoduler finns i Checkout i YAML-schemat.

Bygg-pipelinen checkar ut dina Git-undermoduler så länge de är:

• Oautentiserad: En offentlig, oautentiserad lagringsplats utan autentiseringsuppgifter som krävs för att klona eller hämta.

• Autentiserade:

  • Finns i samma projekt, GitHub-organisation eller Bitbucket Cloud-konto som Git-lagringsplatsen som anges ovan.

  • Har lagts till med hjälp av en URL i förhållande till huvudlagringsplatsen. Den här skulle till exempel checkas ut: git submodule add /../../submodule.git mymodule Den här skulle inte checkas ut: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Autentiserade undermoduler

Kommentar

Kontrollera att du har registrerat dina undermoduler med HTTPS och inte använder SSH.

Samma autentiseringsuppgifter som används av agenten för att hämta källorna från huvudlagringsplatsen används också för att hämta källorna för undermoduler.

Om huvudlagringsplatsen och undermodulerna finns på en Azure Repos Git-lagringsplats i ditt Azure DevOps-projekt kan du välja det konto som används för att komma åt källorna. På fliken Alternativ går du till menyn Skapa jobbauktoriseringsomfång och väljer antingen:

• Projektsamling för att använda project collection build-tjänstkontot

• Aktuellt projekt som ska använda Project Build Service-kontot.

Kontrollera att det konto som du använder har åtkomst till både huvudlagringsplatsen och undermodulerna.

Om huvudlagringsplatsen och undermodulerna finns i samma GitHub-organisation används token som lagras i GitHub-tjänstanslutningen för att komma åt källorna.

Alternativ till att använda alternativet Checkout-undermoduler

I vissa fall kan du inte använda alternativet Checkout-undermoduler . Du kan ha ett scenario där en annan uppsättning autentiseringsuppgifter behövs för att komma åt undermodulerna. Detta kan till exempel inträffa om huvudlagringsplatsen och undermodullagringsplatserna inte lagras i samma Azure DevOps-organisation eller Git-tjänst.

Om du inte kan använda alternativet Checkout-undermoduler kan du i stället använda ett anpassat skriptsteg för att hämta undermoduler. Hämta först en personlig åtkomsttoken (PAT) och prefixet med pat:. Därefter base64-koda den här prefixsträngen för att skapa en grundläggande autentiseringstoken. Lägg slutligen till det här skriptet i pipelinen:

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

Ersätt "<BASIC_AUTH_TOKEN>" med din Base64-kodade token.

Använd en hemlig variabel i projektet eller bygg-pipelinen för att lagra den grundläggande autentiseringstoken som du genererade. Använd variabeln för att fylla i hemligheten i git-kommandot ovan.

Kommentar

F: Varför kan jag inte använda en Git-autentiseringshanterare på agenten?S: Lagring av autentiseringsuppgifter för undermoduler i en Git-autentiseringshanterare som är installerad på din privata byggagent är vanligtvis inte effektivt eftersom autentiseringshanteraren kan uppmana dig att ange autentiseringsuppgifterna igen när undermodulen uppdateras. Detta är inte önskvärt under automatiserade versioner när användarinteraktion inte är möjligt.

Kolla in filer från LFS

Välj om du vill ladda ned filer från stor fillagring (LFS).

I den klassiska redigeraren markerar du kryssrutan för att aktivera det här alternativet.

I en YAML-version lägger du till ett utcheckningssteg med lfs inställt på true:

steps:
- checkout: self
  lfs: true

Om du använder TFS eller om du använder Azure Pipelines med en lokalt installerad agent måste du installera git-lfs på agenten för att det här alternativet ska fungera. Om dina värdbaserade agenter använder Windows kan du överväga att använda variabeln System.PreferGitFromPath för att säkerställa att pipelines använder versionerna av git och git-lfs som du har installerat på datorn. Mer information finns i Vilken version av Git körs min agent?

Använda Git LFS med undermoduler

Om en undermodul innehåller LFS-filer måste Git LFS konfigureras innan du checkar ut undermoduler. De Microsoft-värdbaserade macOS- och Linux-agenterna är förkonfigurerade på det här sättet. Windows-agenter och lokalt installerade macOS-/Linux-agenter kanske inte gör det.

Om du använder YAML kan du lägga till följande steg före :checkout

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

Klona en andra lagringsplats

Som standard är din pipeline associerad med en lagringsplats från Azure Repos eller en extern provider. Det här är lagringsplatsen som kan utlösa byggen på incheckningar och pull-begäranden.

Du kanske vill inkludera källor från en andra lagringsplats i pipelinen. Du kan göra detta genom att skriva ett skript.

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

Om lagringsplatsen inte är offentlig måste du skicka autentisering till Git-kommandot.

Azure-lagringsplatser

Du kan klona flera lagringsplatser i samma projekt som din pipeline med hjälp av utcheckning med flera lagringsplatser.

Om du behöver klona en lagringsplats från ett annat projekt som inte är offentligt måste du autentisera som en användare som har åtkomst till projektet.

Kommentar

Använd en hemlig variabel för att lagra autentiseringsuppgifter på ett säkert sätt.

Hemliga variabler görs inte automatiskt tillgängliga för skript som miljövariabler. Se Hemliga variabler om hur du mappar in dem.

För Azure Repos kan du använda en personlig åtkomsttoken med behörigheten Kod (Läs). Skicka detta som lösenordsfält i auktoriseringshuvudet "Grundläggande" utan användarnamn. (Med andra ord base64-koda värdet :<PAT>för , inklusive kolon.)

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

Synkronisera inte källor

Icke-distributionsjobb hämtar automatiskt källor. Använd det här alternativet om du vill hoppa över det beteendet. Det här alternativet kan vara användbart i de fall då du vill:

• Git-init, konfiguration och hämtning med dina egna anpassade alternativ.

• Använd en byggpipeline för att bara köra automatisering (till exempel vissa skript) som inte är beroende av kod i versionskontrollen.

Om du vill inaktivera nedladdning av källor:

• Azure Pipelines, TFS 2018 och senare: Klicka på Avancerade inställningar och välj sedan Synkronisera inte källor.

Kommentar

När du använder det här alternativet hoppar agenten också över att köra Git-kommandon som rensar lagringsplatsen.

Ytlig hämtning

Välj om du vill begränsa hur långt tillbaka i historiken du vill ladda ned. I praktiken resulterar detta i git fetch --depth=n. Om lagringsplatsen är stor kan det här alternativet göra bygg-pipelinen mer effektiv. Lagringsplatsen kan vara stor om den har använts länge och har en betydande historik. Det kan också vara stort om du har lagt till och senare tagit bort stora filer.

I dessa fall kan det här alternativet hjälpa dig att spara nätverks- och lagringsresurser. Det kan också spara tid. Anledningen till att det inte alltid sparar tid är att servern i vissa situationer kan behöva ägna tid åt att beräkna incheckningarna för att ladda ned för det djup som du anger.

Kommentar

När bygget placeras i kö matchas den gren som ska skapas till ett inchecknings-ID. Sedan hämtar agenten grenen och checkar ut önskad incheckning. Det finns ett litet fönster mellan när en gren matchas till ett inchecknings-ID och när agenten utför utcheckningen. Om grenen uppdateras snabbt och du anger ett mycket litet värde för ytlig hämtning kanske incheckningen inte finns när agenten försöker checka ut den. Om det händer ökar du inställningen för grunt hämtningsdjup.

När du har markerat kryssrutan för att aktivera det här alternativet anger du antalet incheckningar i rutan Djup .

Dricks

Variabeln Agent.Source.Git.ShallowFetchDepth som nämns nedan fungerar också och åsidosätter kryssrutekontrollerna. På så sätt kan du ändra inställningen när du köar bygget.

Föredrar Git från sökväg

Som standard använder Windows-agenten den version av Git som paketeras med agentprogramvaran. Microsoft rekommenderar att du använder den version av Git som medföljer agenten, men du har flera alternativ för att åsidosätta det här standardbeteendet och använda den version av Git som agentdatorn har installerat i sökvägen.

• Ange en pipelinevariabel med namnet System.PreferGitFromPathtrue i dina pipelines.
• På lokalt installerade agenter kan du skapa en fil med namnet .env i agentrotkatalogen och lägga till en System.PreferGitFromPath=true rad i filen. Mer information finns i Hur gör jag för att ange olika miljövariabler för varje enskild agent?

Om du vill se vilken version av Git som används av en pipeline kan du titta på loggarna för ett checkout steg i pipelinen, som du ser i följande exempel.

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

Den här inställningen gäller alltid för icke-Windows-agenter.

Utlösaralternativ för annan Git

När en annan/extern Git-lagringsplats anges kräver CI-versioner att lagringsplatsen är tillgänglig från Internet. Om lagringsplatsen finns bakom en brandvägg eller proxy fungerar endast schemalagda och manuella versioner.

Vanliga frågor

Vilka protokoll kan byggagenten använda med Git?

Agenten stöder HTTPS.

Agenten har ännu inte stöd för SSH. Se Tillåt att build använder SSH-autentisering vid utcheckning av Git-undermoduler.