Skapa Git- eller TFS Git-lagringsplatser för Azure-lagringsplatser

  • Artikel

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

Azure Pipelines kan automatiskt skapa och verifiera varje pull-begäran och checka in till din Azure Repos Git-lagringsplats.

Välj en lagringsplats att skapa

Du skapar en ny pipeline genom att först välja en lagringsplats och sedan en YAML-fil på lagringsplatsen. Lagringsplatsen där YAML-filen finns kallas self lagringsplats. Som standard är det här lagringsplatsen som pipelinen bygger.

Du kan senare konfigurera din pipeline för att checka ut en annan lagringsplats eller flera lagringsplatser. Mer information om hur du gör detta finns i checkouten för flera lagringsplatser.

Azure Pipelines måste beviljas åtkomst till dina lagringsplatser för att utlösa deras versioner och hämta koden under byggen. Normalt har en pipeline åtkomst till lagringsplatser i samma projekt. Men om du vill komma åt lagringsplatser i ett annat projekt måste du uppdatera behörigheterna som beviljats till jobbåtkomsttoken.

CI-utlösare

Utlösare för kontinuerlig integrering (CI) gör att en pipeline körs när du skickar en uppdatering till de angivna grenarna eller push-överför angivna taggar.

YAML-pipelines konfigureras som standard med en CI-utlösare på alla grenar, såvida inte inställningen Inaktivera underförstådda YAML CI-utlösare , som introducerades i Azure DevOps sprint 227, är aktiverad. Inställningen Inaktivera underförstådda YAML CI-utlösare kan konfigureras på organisationsnivå eller på projektnivå. När inställningen Inaktivera underförstådd YAML CI-utlösare är aktiverad aktiveras inte CI-utlösare för YAML-pipelines om YAML-pipelinen inte har något trigger avsnitt. Inaktivera underförstådda YAML CI-utlösare är inte aktiverat som standard.

Grenar

Du kan styra vilka grenar som får CI-utlösare med en enkel syntax:

trigger:
- main
- releases/*

Du kan ange det fullständiga namnet på grenen (till exempel main) eller ett jokertecken (till exempel releases/*). Se Jokertecken för information om jokerteckensyntaxen.

Kommentar

Du kan inte använda variabler i utlösare eftersom variabler utvärderas vid körning (när utlösaren har utlösts).

Kommentar

Om du använder mallar för att skapa YAML-filer kan du bara ange utlösare i yaml-huvudfilen för pipelinen. Du kan inte ange utlösare i mallfilerna.

För mer komplexa utlösare som använder exclude eller batchmåste du använda den fullständiga syntaxen enligt följande exempel.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

I exemplet ovan utlöses pipelinen om en ändring skickas till main eller till någon versionsgren. Det utlöses dock inte om en ändring görs i en versionsgren som börjar med old.

Om du anger en exclude sats utan en include sats motsvarar det att * ange i include -satsen.

Förutom att ange grennamn i branches listorna kan du även konfigurera utlösare baserat på taggar med hjälp av följande format:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Om du inte angav några utlösare och inställningen Inaktivera underförstådda YAML CI-utlösare inte är aktiverad är standardvärdet som om du skrev:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Viktigt!

När du anger en utlösare ersätter den den implicita standardutlösaren och endast push-överföring till grenar som uttryckligen har konfigurerats för att inkluderas utlöser en pipeline. Inkluderar bearbetas först och exkluderingar tas sedan bort från listan.

Batchbearbetning av CI-körningar

Om du ofta har många teammedlemmar som laddar upp ändringar kanske du vill minska antalet körningar som du startar. Om du anger batch till true, när en pipeline körs väntar systemet tills körningen har slutförts och startar sedan en annan körning med alla ändringar som ännu inte har skapats.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Kommentar

batch stöds inte i lagringsplatsens resursutlösare.

För att förtydliga det här exemplet kan vi säga att en push-överföring A orsakade att main pipelinen ovan kördes. När pipelinen körs skickas ytterligare push-överföring B och C sker till lagringsplatsen. Dessa uppdateringar startar inte nya oberoende körningar omedelbart. Men när den första körningen har slutförts skickas alla push-meddelanden tills den tidpunkten batchats ihop och en ny körning startas.

Kommentar

Om pipelinen har flera jobb och faser bör den första körningen fortfarande nå ett terminaltillstånd genom att slutföra eller hoppa över alla jobb och faser innan den andra körningen kan starta. Därför måste du vara försiktig när du använder den här funktionen i en pipeline med flera steg eller godkännanden. Om du vill batcha dina versioner i sådana fall rekommenderar vi att du delar upp CI/CD-processen i två pipelines – en för build (med batchbearbetning) och en för distributioner.

Sekvenser

Du kan ange vilka filsökvägar som ska inkluderas eller exkluderas.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

När du anger sökvägar måste du uttryckligen ange grenar som ska utlösas om du använder Azure DevOps Server 2019.1 eller lägre. Du kan inte utlösa en pipeline med endast ett sökvägsfilter. Du måste också ha ett grenfilter, och de ändrade filerna som matchar sökvägsfiltret måste vara från en gren som matchar grenfiltret. Om du använder Azure DevOps Server 2020 eller senare kan du utelämna branches att filtrera på alla grenar tillsammans med sökvägsfiltret.

Jokertecken stöds för sökvägsfilter. Du kan till exempel inkludera alla sökvägar som matchar src/app/**/myapp*. Du kan använda jokertecken (**, *eller ?) när du anger sökvägsfilter.

  • Sökvägar anges alltid i förhållande till lagringsplatsens rot.
  • Om du inte anger sökvägsfilter inkluderas lagringsplatsens rotmapp implicit som standard.
  • Om du exkluderar en sökväg kan du inte också inkludera den om du inte kvalificerar den till en djupare mapp. Om du till exempel exkluderar /tools kan du inkludera /tools/trigger-runs-on-these
  • Ordningen på sökvägsfilter spelar ingen roll.
  • Sökvägar i Git är skiftlägeskänsliga. Se till att använda samma skiftläge som de riktiga mapparna.
  • Du kan inte använda variabler i sökvägar, eftersom variabler utvärderas vid körning (när utlösaren har utlösts).

Taggar

Förutom att ange taggar i branches listorna som beskrivs i föregående avsnitt kan du ange taggar som ska inkluderas eller exkluderas direkt:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Om du inte anger några taggutlösare utlöser taggar som standard inte pipelines.

Viktigt!

Om du anger taggar i kombination med grenfilter utlöses utlösaren om antingen grenfiltret är uppfyllt eller om taggfiltret är uppfyllt. Om en push-tagg till exempel uppfyller grenfiltret utlöses pipelinen även om taggen undantas av taggfiltret, eftersom push-överföringen uppfyllde grenfiltret.

Avregistrera dig från CI

Inaktivera CI-utlösaren

Du kan välja bort CI-utlösare helt och hållet genom att trigger: noneange .

# A pipeline with no CI trigger
trigger: none

Viktigt!

När du skickar en ändring till en gren utvärderas YAML-filen i den grenen för att avgöra om en CI-körning ska startas.

Hoppar över CI för enskilda push-meddelanden

Du kan också be Azure Pipelines att hoppa över att köra en pipeline som en push normalt utlöser. Inkludera ***NO_CI*** bara i meddelandet för någon av de incheckningar som ingår i en push-överföring, så hoppar Azure Pipelines över att köra CI för den här push-överföringen.

Du kan också be Azure Pipelines att hoppa över att köra en pipeline som en push normalt utlöser. Inkludera [skip ci] bara i meddelandet eller beskrivningen av någon av incheckningarna som ingår i en push-överföring, så hoppar Azure Pipelines över att köra CI för den här push-överföringen. Du kan också använda någon av följande varianter.

  • [skip ci] eller [ci skip]
  • skip-checks: true eller skip-checks:true
  • [skip azurepipelines] eller [azurepipelines skip]
  • [skip azpipelines] eller [azpipelines skip]
  • [skip azp] eller [azp skip]
  • ***NO_CI***

Använda utlösartypen i villkor

Det är ett vanligt scenario att köra olika steg, jobb eller steg i pipelinen beroende på vilken typ av utlösare som startade körningen. Du kan göra detta med hjälp av systemvariabeln Build.Reason. Lägg till exempel till följande villkor i ditt steg, jobb eller steg för att undanta det från PR-valideringar.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Beteende för utlösare när nya grenar skapas

Det är vanligt att konfigurera flera pipelines för samma lagringsplats. Du kan till exempel ha en pipeline för att skapa dokumenten för din app och en annan för att skapa källkoden. Du kan konfigurera CI-utlösare med lämpliga förgreningsfilter och sökvägsfilter i var och en av dessa pipelines. Du kanske till exempel vill att en pipeline ska utlösas när du skickar en uppdatering till docs mappen och en annan ska utlösas när du skickar en uppdatering till programkoden. I dessa fall måste du förstå hur pipelines utlöses när en ny gren skapas.

Här är beteendet när du skickar en ny gren (som matchar grenfiltren) till lagringsplatsen:

  • Om din pipeline har sökvägsfilter utlöses den endast om den nya grenen har ändringar i filer som matchar sökvägsfiltret.
  • Om pipelinen inte har sökvägsfilter utlöses den även om det inte finns några ändringar i den nya grenen.

Jokertecken

När du anger en gren, tagg eller sökväg kan du använda ett exakt namn eller ett jokertecken. Med jokertecken kan * mönster matcha noll eller fler tecken och ? matcha ett enda tecken.

  • Om du startar mönstret med * i en YAML-pipeline måste du omsluta mönstret med citattecken, till exempel "*-releases".
  • För grenar och taggar:
    • Ett jokertecken kan visas var som helst i mönstret.
  • För sökvägar:
    • I Azure DevOps Server 2022 och senare, inklusive Azure DevOps Services, kan ett jokertecken visas var som helst inom ett sökvägsmönster och du kan använda * eller ?.
    • I Azure DevOps Server 2020 och lägre kan du inkludera * som det sista tecknet, men det gör inget annat än att ange katalognamnet på egen hand. Du kanske inte tar med * i mitten av ett sökvägsfilter och du kanske inte använder ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR-utlösare

Pull-begärandeutlösare (PR) gör att en pipeline körs när du öppnar en pull-begäran eller när du skickar ändringar till den. I Azure Repos Git implementeras den här funktionen med hjälp av grenprinciper. Om du vill aktivera PR-validering går du till grenprinciperna för den önskade grenen och konfigurerar build-valideringsprincipen för den grenen. Mer information finns i Konfigurera grenprinciper.

Om du har en öppen PR och skickar ändringar till dess källgren kan flera pipelines köras:

  • Pipelines som anges av målgrenens byggvalideringsprincip körs vid sammanslagningsincheckningen (den sammanfogade koden mellan käll- och målgrenarna för pull-begäran), oavsett om det finns push-incheckningar vars meddelanden eller beskrivningar innehåller [skip ci] (eller någon av dess varianter).
  • Pipelines som utlöses av ändringar i PR:s källgren, om det inte finns några push-incheckningar vars meddelanden eller beskrivningar innehåller [skip ci] (eller någon av dess varianter). Om minst en push-överföring innehåller [skip ci]körs inte pipelines.

När du har slagit samman pr-filen kör Azure Pipelines slutligen CI-pipelines som utlöses av push-meddelanden till målgrenen, även om några av de sammanfogade incheckningarnas meddelanden eller beskrivningar innehåller [skip ci] (eller någon av dess varianter).

Kommentar

Om du vill konfigurera valideringsversioner för en Git-lagringsplats för Azure Repos måste du vara projektadministratör för projektet.

Kommentar

Utkast pull-begäranden utlöser inte en pipeline även om du konfigurerar en grenprincip.

Verifiera bidrag från förgreningar

Att skapa pull-begäranden från Azure Repos-förgreningar skiljer sig inte från att skapa pull-begäranden på samma lagringsplats eller projekt. Du kan bara skapa förgreningar inom samma organisation som projektet ingår i.

Begränsa omfånget för jobbauktorisering

Azure Pipelines innehåller flera säkerhetsinställningar för att konfigurera det jobbauktoriseringsomfång som dina pipelines körs med.

Begränsa jobbauktoriseringsomfånget till aktuellt projekt

Azure Pipelines tillhandahåller två begränsa jobbauktoriseringsomfånget till aktuella projektinställningar :

  • Begränsa omfånget för jobbauktorisering till aktuellt projekt för pipelines som inte släpps – den här inställningen gäller för YAML-pipelines och klassiska byggpipelines. Den här inställningen gäller inte för klassiska versionspipelines.
  • Begränsa omfånget för jobbauktorisering till aktuellt projekt för versionspipelines – Den här inställningen gäller endast för klassiska versionspipelines .

Pipelines körs med åtkomsttoken med samlingsomfång såvida inte relevant inställning för pipelinetypen är aktiverad. Med inställningarna Begränsa jobbauktoriseringsomfång kan du minska åtkomstomfånget för alla pipelines till det aktuella projektet. Detta kan påverka din pipeline om du har åtkomst till en Azure Repos Git-lagringsplats i ett annat projekt i din organisation.

Om Git-lagringsplatsen för Azure Repos finns i ett annat projekt än din pipeline och inställningen Begränsa omfång för jobbauktorisering för din pipelinetyp är aktiverad måste du ge behörighet till byggtjänstidentiteten för pipelinen till det andra projektet. Mer information finns i Hantera behörigheter för byggtjänstkonto.

Azure Pipelines tillhandahåller en säkerhetsinställning för att konfigurera det jobbauktoriseringsomfång som dina pipelines kör med.

  • Begränsa omfånget för jobbauktorisering till aktuellt projekt – Den här inställningen gäller yaml-pipelines och klassiska byggpipelines. Den här inställningen gäller inte för klassiska versionspipelines.

Pipelines körs med åtkomsttoken med samlingsomfång såvida inte Begränsa jobbets auktoriseringsomfång till det aktuella projektet är aktiverat. Med den här inställningen kan du minska åtkomstomfånget för alla pipelines till det aktuella projektet. Detta kan påverka din pipeline om du har åtkomst till en Azure Repos Git-lagringsplats i ett annat projekt i din organisation.

Om git-lagringsplatsen för Azure Repos finns i ett annat projekt än din pipeline och inställningen Begränsa omfång för jobbauktorisering är aktiverad måste du ge behörighet till byggtjänstidentiteten för din pipeline till det andra projektet. Mer information finns i Auktoriseringsområde för jobb.

Mer information om Begränsa omfånget för jobbauktorisering finns i Förstå åtkomsttoken för jobb.

Begränsa omfånget för jobbauktorisering till refererade Azure DevOps-lagringsplatser

Pipelines kan komma åt alla Azure DevOps-lagringsplatser i auktoriserade projekt, enligt beskrivningen i det tidigare avsnittet Begränsa jobbauktorisering till aktuellt projekt , såvida inte Begränsa jobbauktoriseringsomfånget till refererade Azure DevOps-lagringsplatser är aktiverat. Med det här alternativet aktiverat kan du minska åtkomstomfånget för alla pipelines till endast Azure DevOps-lagringsplatser som uttryckligen refereras till med ett checkout steg eller en uses instruktion i pipelinejobbet som använder lagringsplatsen.

Om du vill konfigurera den här inställningen går du till Pipelines, Inställningar på antingen Organisationsinställningar eller Projektinställningar. Om inställningen är aktiverad på organisationsnivå är den nedtonad och otillgänglig på projektinställningsnivå.

När Begränsa jobbauktoriseringsomfånget till refererade Azure DevOps-lagringsplatser är aktiverat måste YAML-pipelines uttryckligen referera till alla Azure Repos Git-lagringsplatser som du vill använda i pipelinen som ett utcheckningssteg i jobbet som använder lagringsplatsen. Du kommer inte att kunna hämta kod med hjälp av skriptuppgifter och git-kommandon för en Azure Repos Git-lagringsplats om inte lagringsplatsen först uttryckligen refereras till.

Det finns några undantag där du inte uttryckligen behöver referera till en Azure Repos Git-lagringsplats innan du använder den i pipelinen när Begränsa jobbauktoriseringsomfånget till refererade Azure DevOps-lagringsplatser är aktiverat.

  • Om du inte har ett explicit utcheckningssteg i pipelinen är det som om du har ett checkout: self steg och self lagringsplatsen är utcheckad.
  • Om du använder ett skript för att utföra skrivskyddade åtgärder på en lagringsplats i ett offentligt projekt behöver du inte referera till den offentliga projektlagringsplatsen i ett checkout steg.
  • Om du använder ett skript som tillhandahåller sin egen autentisering till lagringsplatsen, till exempel en PAT, behöver du inte referera till lagringsplatsen i ett checkout steg.

När till exempel Begränsa jobbauktoriseringsomfånget till refererade Azure DevOps-lagringsplatser är aktiverat, om din pipeline finns på FabrikamProject/Fabrikam lagringsplatsen i din organisation och du vill använda ett skript för att checka ut lagringsplatsen, måste du antingen referera till den FabrikamProject/FabrikamTools här lagringsplatsen i ett checkout steg eller med en uses instruktion.

Om du redan checkar ut FabrikamTools lagringsplatsen i pipelinen med hjälp av ett utcheckningssteg kan du senare använda skript för att interagera med lagringsplatsen.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Kommentar

I många scenarier kan du checka ut flera lagringsplatser, vilket tar bort behovet av att använda skript för att kolla in ytterligare lagringsplatser i pipelinen. Mer information finns i Kolla in flera lagringsplatser i pipelinen.

Skydda åtkomsten till lagringsplatser i YAML-pipelines

Pipelines kan komma åt alla Azure DevOps-lagringsplatser i auktoriserade projekt, enligt beskrivningen i föregående Avsnittet Begränsa jobbauktorisering till aktuellt projekt , såvida inte Skydda åtkomsten till lagringsplatser i YAML-pipelines är aktiverad. Med det här alternativet aktiverat kan du minska åtkomstomfånget för alla pipelines till endast Azure DevOps-lagringsplatser som uttryckligen refereras till med ett checkout steg eller en uses instruktion i pipelinejobbet som använder lagringsplatsen.

Om du vill konfigurera den här inställningen går du till Pipelines, Inställningar på antingen Organisationsinställningar eller Projektinställningar. Om inställningen är aktiverad på organisationsnivå är den nedtonad och otillgänglig på projektinställningsnivå.

Viktigt!

Skydda åtkomsten till lagringsplatser i YAML-pipelines är aktiverad som standard för nya organisationer och projekt som skapats efter maj 2020. När Skydda åtkomsten till lagringsplatser i YAML-pipelines är aktiverad måste YAML-pipelines uttryckligen referera till alla Azure Repos Git-lagringsplatser som du vill använda i pipelinen som ett utcheckningssteg i jobbet som använder lagringsplatsen. Du kommer inte att kunna hämta kod med hjälp av skriptuppgifter och git-kommandon för en Azure Repos Git-lagringsplats om inte lagringsplatsen först uttryckligen refereras till.

Det finns några undantag där du inte uttryckligen behöver referera till en Azure Repos Git-lagringsplats innan du använder den i pipelinen när Skydda åtkomst till lagringsplatser i YAML-pipelines är aktiverat.

  • Om du inte har ett explicit utcheckningssteg i pipelinen är det som om du har ett checkout: self steg och self lagringsplatsen är utcheckad.
  • Om du använder ett skript för att utföra skrivskyddade åtgärder på en lagringsplats i ett offentligt projekt behöver du inte referera till den offentliga projektlagringsplatsen i ett checkout steg.
  • Om du använder ett skript som tillhandahåller sin egen autentisering till lagringsplatsen, till exempel en PAT, behöver du inte referera till lagringsplatsen i ett checkout steg.

När till exempel Skydda åtkomst till lagringsplatser i YAML-pipelines är aktiverat, om din pipeline finns på FabrikamProject/Fabrikam lagringsplatsen i din organisation och du vill använda ett skript för att checka ut lagringsplatsen, måste du antingen referera till den FabrikamProject/FabrikamTools här lagringsplatsen i ett checkout steg eller med en uses instruktion.

Om du redan checkar ut FabrikamTools lagringsplatsen i pipelinen med hjälp av ett utcheckningssteg kan du senare använda skript för att interagera med lagringsplatsen.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Kommentar

I många scenarier kan du checka ut flera lagringsplatser, vilket tar bort behovet av att använda skript för att kolla in ytterligare lagringsplatser i pipelinen. Mer information finns i Kolla in flera lagringsplatser i pipelinen.

Utcheckning

När en pipeline utlöses hämtar Azure Pipelines källkoden från Git-lagringsplatsen för Azure Repos. Du kan styra olika aspekter av hur detta sker.

Kommentar

När du inkluderar ett utcheckningssteg i pipelinen kör vi följande kommando: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Om detta inte uppfyller dina behov kan du välja att exkludera den inbyggda utcheckningen och checkout: none sedan använda en skriptuppgift för att utföra en egen utcheckning.

Önskad version av Git

Windows-agenten levereras med en egen kopia av Git. Om du föredrar att ange din egen Git i stället för att använda den medföljande kopian anger du System.PreferGitFromPath till true. Den här inställningen gäller alltid för icke-Windows-agenter.

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

Du kan konfigurera inställningen path i utcheckningssteget i din pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Submodules

Du kan konfigurera inställningen submodules i utcheckningssteget i pipelinen om du vill ladda ned filer från undermoduler.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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 som Git-lagringsplatsen för Azure Repos som anges ovan. 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.

    • Har lagts till med hjälp av en URL i förhållande till huvudlagringsplatsen. Till exempel

      • Den här skulle checkas ut: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        I det här exemplet refererar undermodulen till en lagringsplats (FabrikamFiber) i samma Azure DevOps-organisation, men i ett annat projekt (FabrikamFiberProject). 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. Detta kräver att jobbåtkomsttoken har åtkomst till lagringsplatsen i det andra projektet. Om du har begränsat token för jobbåtkomst enligt beskrivningen i avsnittet ovan kan du inte göra det. Du kan tillåta att jobbåtkomsttoken får åtkomst till lagringsplatsen i det andra projektet genom att antingen (a) uttryckligen bevilja åtkomst till project build-tjänstkontot i det andra projektet eller (b) med hjälp av åtkomsttoken med samlingsomfång i stället för projektomfångstoken för hela organisationen. Mer information om dessa alternativ och deras säkerhetskonsekvenser finns i Åtkomstlagringsplatser, artefakter och andra resurser.

      • Den här skulle inte checkas ut: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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 om din jobbåtkomsttoken inte har åtkomst till lagringsplatsen i ett annat projekt.

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

Ersätt "<BASE64_ENCODED_STRING>" med din Base64-kodade "pat:token"-sträng.

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.

Synkroniseringstaggar

Viktigt!

Funktionen för synkroniseringstaggar stöds i Azure Repos Git med Azure DevOps Server 2022.1 och senare.

I utcheckningssteget --tags används alternativet när innehållet på en Git-lagringsplats hämtas. Detta gör att servern hämtar alla taggar samt alla objekt som pekas på av dessa taggar. Detta ökar tiden för att köra aktiviteten i en pipeline, särskilt om du har en stor lagringsplats med ett antal taggar. Dessutom synkroniserar utcheckningssteget taggar även när du aktiverar det grunda hämtningsalternativet, vilket möjligen kan besegra dess syfte. För att minska mängden data som hämtas eller hämtas från en Git-lagringsplats har Microsoft lagt till ett nytt alternativ för att checka ut för att kontrollera beteendet för synkroniseringstaggar. Det här alternativet är tillgängligt både i klassiska pipelines och YAML-pipelines.

Om du vill synkronisera taggar när du checkar ut en lagringsplats kan konfigureras i YAML genom att ange fetchTags egenskapen och i användargränssnittet genom att konfigurera inställningen Synkroniseringstaggar .

Du kan konfigurera inställningen fetchTags i utcheckningssteget i din pipeline.

Ange egenskapen för fetchTags att konfigurera inställningen i YAML.

steps:
- checkout: self
  fetchTags: true

Du kan också konfigurera den här inställningen med alternativet Synkroniseringstaggar i användargränssnittet för pipelineinställningar.

  1. Redigera YAML-pipelinen och välj Fler åtgärder, Utlösare.

    Skärmbild av menyn för fler utlösare.

  2. Välj YAML, Hämta källor.

    Skärmbild av Hämta källor.

  3. Konfigurera inställningen Synkronisera taggar.

    Skärmbild av inställningen Synkronisera taggar.

Kommentar

Om du uttryckligen anger fetchTags i steget checkout prioriteras den inställningen framför inställningen som konfigurerats i användargränssnittet för pipelineinställningar.

Standardbeteende

  • För befintliga pipelines som skapats före lanseringen av Azure DevOps sprint 209, som släpptes i september 2022, förblir standardvärdet för synkroniseringstaggar detsamma som det befintliga beteendet innan alternativen för synkroniseringstaggar lades till, vilket är true.
  • För nya pipelines som skapats efter Azure DevOps sprint version 209 är falsestandardinställningen för synkroniseringstaggar .

Kommentar

Om du uttryckligen anger fetchTags i steget checkout prioriteras den inställningen framför inställningen som konfigurerats i användargränssnittet för pipelineinställningar.

Ytlig hämtning

Du kanske vill begränsa hur långt tillbaka i historiken som ska laddas 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.

Viktigt!

Nya pipelines som skapats efter uppdateringen av Azure DevOps sprint 209 i september 2022 har Shallow-hämtning aktiverat som standard och konfigurerats med ett djup på 1. Tidigare var standardvärdet inte för ytlig hämtning. Om du vill kontrollera din pipeline kan du visa inställningen Shallow fetch i UI för pipelineinställningar enligt beskrivningen i följande avsnitt.

Du kan konfigurera inställningen fetchDepth i utcheckningssteget i din pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Du kan också konfigurera hämtningsdjup genom att ange alternativet Grunt djup i pipelineinställningarnas användargränssnitt.

  1. Redigera YAML-pipelinen och välj Fler åtgärder, Utlösare.

    Skärmbild av menyn för fler utlösare.

  2. Välj YAML, Hämta källor.

    Skärmbild av Hämta källor.

  3. Konfigurera inställningen Grunt hämtning. Avmarkera Grunt hämtning för att inaktivera ytlig hämtning, eller markera kryssrutan och ange ett djup för att aktivera ytlig hämtning.

    Skärmbild av alternativ.

Kommentar

Om du uttryckligen anger fetchDepth i steget checkout prioriteras den inställningen framför inställningen som konfigurerats i användargränssnittet för pipelineinställningar. Inställningen fetchDepth: 0 hämtar all historik och åsidosätter inställningen Shallow fetch .

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 pipelinen startas matchas grenen 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.

Synkronisera inte källor

Du kanske vill hoppa över att hämta nya incheckningar. 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 versionskontroll.

Du kan konfigurera inställningen Synkronisera inte källor i utcheckningsstegeti din pipeline genom att ange checkout: none.

steps:
- checkout: none  # Don't sync sources

Kommentar

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

Rensa version

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.

Du kan konfigurera inställningen clean i utcheckningssteget i din pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

När clean är inställt true på bygg-pipelinen utför en ångra av eventuella ändringar i $(Build.SourcesDirectory). Mer specifikt körs följande Git-kommandon innan källan hämtas.

git clean -ffdx
git reset --hard HEAD

Om du vill ha fler alternativ kan du konfigurera inställningen för workspace ett jobb.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Detta ger följande rena alternativ.

  • utdata: Samma åtgärd som den rena inställningen som beskrivs i föregående utcheckningsaktivitet, 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.

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

  • alla: 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.

Du kan för närvarande inte konfigurera den här inställningen i YAML, men det kan du i den klassiska redigeraren. När du redigerar en YAML-pipeline kan du komma åt den klassiska redigeraren genom att välja antingen Utlösare från YAML-redigerarmenyn.

Konfigurera Git-alternativ, YAML.

I den klassiska redigeraren väljer du YAML, väljer uppgiften Hämta källor och konfigurerar sedan önskade egenskaper där.

I den klassiska redigeraren väljer du YAML > Hämta källor.

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

Vanliga frågor

Problem som rör Integrering av Azure Repos finns i tre kategorier:

  • Utlösare som misslyckas: Min pipeline utlöses inte när jag skickar en uppdatering till lagringsplatsen.
  • Misslyckad utcheckning: Min pipeline utlöses, men den misslyckas i utcheckningssteget.
  • Fel version: Min pipeline körs, men den använder en oväntad version av källan/YAML.

Felutlösare

Jag har precis skapat en ny YAML-pipeline med CI/PR-utlösare, men pipelinen utlöses inte.

Följ vart och ett av dessa steg för att felsöka dina felutlösare:

  • Åsidosättas dina YAML CI- eller PR-utlösare av pipelineinställningar i användargränssnittet? När du redigerar din pipeline väljer du ... och sedan Utlösare.

    Användargränssnitt för pipelineinställningar.

    Kontrollera inställningen Åsidosätt YAML-utlösaren härifrån för de typer av utlösare (kontinuerlig integrering eller validering av pull-begäran) som är tillgängliga för lagringsplatsen.

    Åsidosätt YAML-utlösare härifrån.

  • Konfigurerar du PR-utlösaren i YAML-filen eller i grenprinciper för lagringsplatsen? För en Git-lagringsplats för Azure Repos kan du inte konfigurera en PR-utlösare i YAML-filen. Du måste använda grenprinciper.

  • Har pipelinen pausats eller inaktiverats? Öppna redigeraren för pipelinen och välj sedan Inställningar att kontrollera. Om pipelinen är pausad eller inaktiverad fungerar inte utlösare.

  • Har du uppdaterat YAML-filen i rätt gren? Om du skickar en uppdatering till en gren styr YAML-filen i samma gren CI-beteendet. Om du skickar en uppdatering till en källgren styr YAML-filen som uppstår när källgrenen slås samman med målgrenen PR-beteendet. Kontrollera att YAML-filen i rätt gren har nödvändig CI- eller PR-konfiguration.

  • Har du konfigurerat utlösaren korrekt? När du definierar en YAML-utlösare kan du ange både inkludera och exkludera satser för grenar, taggar och sökvägar. Se till att inkluderingssatsen matchar informationen om incheckningen och att exkluderingssatsen inte utesluter dem. Kontrollera syntaxen för utlösarna och kontrollera att den är korrekt.

  • Har du använt variabler för att definiera utlösaren eller sökvägarna? Det stöds inte.

  • Använde du mallar för YAML-filen? I så fall kontrollerar du att utlösarna har definierats i yaml-huvudfilen. Utlösare som definieras i mallfiler stöds inte.

  • Har du exkluderat de grenar eller sökvägar som du har push-överfört ändringarna till? Testa genom att push-överföra en ändring till en inkluderad sökväg i en inkluderad gren. Observera att sökvägarna i utlösare är skiftlägeskänsliga. Kontrollera att du använder samma skiftläge som för riktiga mappar när du anger sökvägarna i utlösare.

  • Har du precis push-överfört en ny gren? I så fall kanske den nya grenen inte startar en ny körning. Se avsnittet "Beteende för utlösare när nya grenar skapas".

Mina CI- eller PR-utlösare har fungerat bra. Men de slutade fungera nu.

Gå först igenom felsökningsstegen i föregående fråga. Följ sedan dessa ytterligare steg:

  • Har du sammanslagningskonflikter i din PR? För en PR som inte utlöste en pipeline öppnar du den och kontrollerar om den har en sammanslagningskonflikt. Lös sammanslagningskonflikten.

  • Har du en fördröjning i bearbetningen av push- eller PR-händelser? Du kan vanligtvis kontrollera detta genom att se om problemet är specifikt för en enda pipeline eller är gemensamt för alla pipelines eller lagringsplatser i projektet. Om en push- eller PR-uppdatering till någon av lagringsplatserna uppvisar det här symptomet kan det uppstå fördröjningar i bearbetningen av uppdateringshändelserna. Kontrollera om det uppstår ett avbrott i tjänsten på statussidan. Om statussidan visar ett problem måste vårt team redan ha börjat arbeta med det. Kontrollera sidan ofta för att få uppdateringar om problemet.

Jag vill inte att användarna ska åsidosätta listan över grenar för utlösare när de uppdaterar YAML-filen. Hur gör jag?

Användare med behörighet att bidra med kod kan uppdatera YAML-filen och inkludera/exkludera ytterligare grenar. Därför kan användarna inkludera sin egen funktion eller användargren i sin YAML-fil och skicka uppdateringen till en funktion eller användargren. Detta kan leda till att pipelinen utlöses för alla uppdateringar av den grenen. Om du vill förhindra det här beteendet kan du:

  1. Redigera pipelinen i Azure Pipelines-användargränssnittet.
  2. Gå till menyn Utlösare .
  3. Välj Åsidosätt utlösaren för kontinuerlig integrering av YAML härifrån.
  4. Ange vilka grenar som ska inkluderas eller exkluderas för utlösaren.

När du följer de här stegen ignoreras alla CI-utlösare som anges i YAML-filen.

Jag har flera lagringsplatser i min YAML-pipeline. Hur konfigurerar jag utlösare för varje lagringsplats?

Se utlösare i Använda flera lagringsplatser.

Misslyckad utcheckning

Jag ser följande fel i loggfilen under utcheckningssteget. Hur åtgärdar jag detta?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Följ vart och ett av dessa steg för att felsöka din misslyckade utcheckning:

  • Finns lagringsplatsen fortfarande? Kontrollera först att det gör det genom att öppna det på sidan Lagringsplatser .

  • Har du åtkomst till lagringsplatsen med hjälp av ett skript? I så fall kontrollerar du inställningen Begränsa jobbauktorisering till refererade Azure DevOps-lagringsplatser . När Begränsa jobbauktoriseringsomfånget till refererade Azure DevOps-lagringsplatser är aktiverat kan du inte checka ut Azure Repos Git-lagringsplatser med hjälp av ett skript såvida de inte uttryckligen refereras först i pipelinen.

  • Vad är omfånget för jobbauktorisering för pipelinen?

    • Om omfånget är samling:

      • Det kan vara ett tillfälligt fel. Kör pipelinen igen.
      • Någon kan ha tagit bort åtkomsten till Project Collection Build Service-kontot.
        • Gå till Projektinställningar för projektet där lagringsplatsen finns. Välj Lagringsplatser >> specifik lagringsplats och sedan Säkerhet.
        • Kontrollera om Project Collection Build Service (ditt samlingsnamn) finns i listan över användare.
        • Kontrollera om kontot har åtkomsten Skapa tagg och Läs .

    • Om omfånget är projekt:

      • Finns lagringsplatsen i samma projekt som pipelinen?
        • Ja:
          • Det kan vara ett tillfälligt fel. Kör pipelinen igen.
          • Någon kan ha tagit bort åtkomsten till Project Build Service-kontot.
            • Gå till Projektinställningar för projektet där lagringsplatsen finns. Välj Lagringsplatser >> specifik lagringsplats och sedan Säkerhet.
            • Kontrollera om byggtjänsten för ditt projektnamn (ditt samlingsnamn) finns i listan över användare.
            • Kontrollera om kontot har åtkomsten Skapa tagg och Läs .
        • Nej:

Fel version

En fel version av YAML-filen används i pipelinen. Varför är den det?

  • För CI-utlösare utvärderas YAML-filen som finns i grenen som du pushar för att se om en CI-version ska köras.
  • För PR-utlösare utvärderas YAML-filen som härrör från sammanslagning av käll- och målgrenarna för PR för att se om en PR-version ska köras.