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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

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.

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

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.PreferGitFromPath true 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 ställer jag in 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.