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.
Kommentar
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. Du kan använda Skapa artefakter för att dela utdata från en pipelinekörning, ett steg eller ett jobb med efterföljande körningar, faser eller jobb.
Azure Pipelines, Azure DevOps Server 2019 och senare
Det finns flera olika rena alternativ för YAML-pipelines.
- Steget
checkouthar ettcleanalternativ. När den är inställdtruepå körsexecute git clean -ffdx && git reset --hard HEADpipelinen innan lagringsplatsen hämtas. Mer information finns i Checkout. - Inställningen
workspaceförjobhar 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: trueange för varjecheckoutsteg i pipelinen. Så här konfigurerar du inställningen Rensa :Redigera din pipeline, välj ...och välj Utlösare.
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.
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 mymoduleDen 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 autentiseringsuppgifterna för undermodulen 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
Din pipeline har redan åtkomst till andra lagringsplatser i projektet och du kan klona dem i pipelinen med hjälp av ett skriptkommando, som du ser i följande exempel.
- script: |
git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame
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.PreferGitFromPathtruei dina pipelines. - På lokalt installerade agenter kan du skapa en fil med namnet .env i agentrotkatalogen och lägga till en
System.PreferGitFromPath=truerad 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.
Jag använder TFS lokalt och jag ser inte några av dessa funktioner. Varför inte?
Vissa av dessa funktioner är endast tillgängliga i Azure Pipelines och är ännu inte tillgängliga lokalt. Vissa funktioner är tillgängliga lokalt om du har uppgraderat till den senaste versionen av TFS.