Vytváření úložišť Git nebo TFS Git v Azure Repos

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

Azure Pipelines může automaticky sestavovat a ověřovat všechny žádosti o přijetí změn a potvrdit je do úložiště Git Azure Repos.

Zvolte úložiště, které se má sestavit.

YAML

Nový kanál vytvoříte tak, že nejprve vyberete úložiště a pak soubor YAML v daném úložišti. Úložiště, ve kterém se nachází soubor YAML, se nazývá self úložiště. Ve výchozím nastavení se jedná o úložiště, které vaše kanály sestavují.

Později můžete kanál nakonfigurovat tak, aby si zkontroloval jiné úložiště nebo více úložišť. Informace o tom, jak to udělat, najdete v pokladně s více úložišti.

Klasické

Při vytváření kanálu vyberte úložiště, které se má sestavit, nejprve vyberte projekt, do kterého úložiště patří. Pak vyberte úložiště.

Klonování dalších úložišť v rámci kanálu:

• Pokud je úložiště ve stejném projektu jako váš kanál nebo pokud má přístupový token (vysvětleno níže) přístup k úložišti v jiném projektu, použijte následující příkaz:

  git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" <clone URL>

  Abyste mohli skript použít System.AccessToken , musíte ho nejdřív zpřístupnit skriptu. Uděláte to tak, že v editoru vyberete úlohu na kartě Úkoly , v pravém panelu vyberete Další možnosti a zaškrtnete možnost Povolit skriptům přístup k tokenu OAuth.

• Pokud přístupový token (vysvětleno níže) nemá přístup k úložišti:

  1. Získání tokenu PAT s oborem Code (read) a předpona tokenu PATPAT:
  2. Zakódování base64 tohoto řetězce za účelem vytvoření základního ověřovacího tokenu
  3. Přidejte do kanálu skript pomocí následujícího příkazu, který naklonuje toto úložiště. git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

Azure Pipelines musí mít udělený přístup k vašim úložištím, aby bylo možné aktivovat sestavení a načíst kód během sestavení. Kanál má obvykle přístup k úložištím ve stejném projektu. Pokud ale chcete přistupovat k úložištím v jiném projektu, musíte aktualizovat oprávnění udělená pro přístupové tokeny úloh.

Triggery CI

Triggery kontinuální integrace (CI) způsobují spuštění kanálu při každém nasdílení aktualizace do zadaných větví nebo nabízení zadaných značek.

YAML

Kanály YAML se ve výchozím nastavení konfigurují s triggerem CI ve všech větvích, pokud není povolené nastavení zakázat implicitní aktivační událost YAML CI, zavedené ve sprintu Azure DevOps 227. Zakázat implicitní nastavení triggeru CI PRO YAML je možné nakonfigurovat na úrovni organizace nebo na úrovni projektu. Pokud je povolené nastavení implicitní aktivační události YAML CI, triggery CI pro kanály YAML nejsou povoleny, pokud kanál YAML nemá trigger oddíl. Ve výchozím nastavení není povolená implicitní aktivační událost CI JAZYKa YAML.

Větve

Pomocí jednoduché syntaxe můžete určit, které větve získávají triggery CI:

trigger:
- main
- releases/*

Můžete zadat úplný název větve (například main) nebo zástupný znak (například releases/*). Informace o syntaxi zástupných znaků najdete v části Zástupné cardy .

Poznámka:

Proměnné nelze použít v triggerech, protože proměnné se vyhodnocují za běhu (po aktivaci triggeru).

Poznámka:

Pokud k vytváření souborů YAML používáte šablony , můžete pro kanál zadat pouze triggery v hlavním souboru YAML. V souborech šablon nelze zadat aktivační události.

Pro složitější triggery, které používají exclude nebo batch, musíte použít úplnou syntaxi, jak je znázorněno v následujícím příkladu.

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

V předchozím příkladu se kanál aktivuje, pokud se změny nasdílí do main nebo do jakékoli větve vydané verze. Pokud se ale provede změna větve vydané verze, která začíná oldna , se neaktivuje.

Pokud zadáte exclude klauzuli bez include klauzule, je ekvivalentní k určení * v klauzuli include .

Kromě zadávání názvů větví v branches seznamech můžete také nakonfigurovat triggery založené na značkách pomocí následujícího formátu:

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

Pokud jste nezadali žádné aktivační události a není povolené nastavení implicitní aktivační události YAML CI, výchozí hodnota je, jako byste napsali:

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

Důležité

Když zadáte trigger, nahradí výchozí implicitní trigger a aktivuje kanál pouze do větví, které jsou explicitně nakonfigurované tak, aby byly zahrnuty. Zahrnutí se nejprve zpracuje a pak se z daného seznamu odeberou vyloučení.

Dávkové spuštění CI

Pokud máte mnoho členů týmu, kteří často nahrávají změny, můžete snížit počet spuštění, která začínáte. Pokud nastavíte hodnotu batch true, když je kanál spuštěný, systém počká, dokud se spuštění nedokončí, spustí další spuštění se všemi změnami, které ještě nebyly vytvořeny.

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

Poznámka:

batch triggery prostředků úložiště se nepodporují.

Abychom tento příklad vysvětlili, řekněme, že nabízené oznámení A main způsobilo spuštění výše uvedeného kanálu. Během spuštění tohoto kanálu se do úložiště nasdílí B C další nabízené změny. Tyto aktualizace nespustí nové nezávislé spuštění okamžitě. Po dokončení prvního spuštění se ale všechny změny odesílají do dávkového časového bodu a spustí se nové spuštění.

Poznámka:

Pokud má kanál více úloh a fází, měl by první spuštění stále dosáhnout stavu terminálu dokončením nebo přeskočením všech úloh a fází před spuštěním druhého spuštění. Z tohoto důvodu musíte při použití této funkce v kanálu s několika fázemi nebo schváleními postupovat opatrně. Pokud chcete sestavení v takových případech dávkot, doporučujeme rozdělit proces CI/CD na dva kanály – jeden pro sestavení (s dávkováním) a druhý pro nasazení.

Cesty

Můžete zadat cesty k souborům, které chcete zahrnout nebo vyloučit.

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

Při zadávání cest musíte explicitně zadat větve, které se mají aktivovat, pokud používáte Azure DevOps Server 2019.1 nebo nižší. Kanál nejde aktivovat pouze s filtrem cesty; Musíte mít také filtr větve a změněné soubory, které odpovídají filtru cesty, musí být z větve, která odpovídá filtru větve. Pokud používáte Azure DevOps Server 2020 nebo novější, můžete ve spojení s filtrem cesty vynechat branches filtrování všech větví.

Filtry cest podporují zástupné znaky. Můžete například zahrnout všechny cesty, které odpovídají src/app/**/myapp*. Můžete použít zástupné znaky (***nebo ?) při zadávání filtrů cest).

• Cesty se vždy zadají vzhledem ke kořenovému adresáři úložiště.
• Pokud nenastavíte filtry cest, kořenová složka úložiště se implicitně zahrne do výchozího nastavení.
• Pokud cestu vyloučíte, nemůžete ji zahrnout ani v případě, že ji opravíte k hlubší složce. Pokud například vyloučíte /tools , můžete zahrnout /tools/trigger-runs-on-these
• Pořadífiltrůch
• Cesty v Gitu rozlišují malá a velká písmena. Nezapomeňte použít stejný případ jako skutečné složky.
• Proměnné nemůžete použít v cestách, protože proměnné se vyhodnocují za běhu (po aktivaci triggeru).

Značky

Kromě zadávání značek v branches seznamech, jak je popsáno v předchozí části, můžete přímo zadat značky, které se mají zahrnout nebo vyloučit:

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

Pokud nezadáte žádné aktivační události značek, ve výchozím nastavení se značky neaktivují kanály.

Důležité

Pokud zadáte značky v kombinaci s filtry větví, trigger se aktivuje, pokud je filtr větve splněný nebo je filtr značek splněný. Pokud například vložená značka splňuje filtr větve, kanál se aktivuje i v případě, že je značka vyloučena filtrem značek, protože nabízená oznámení splnila filtr větve.

Odhlášení z CI

Zakázání triggeru CI

Můžete se úplně odhlásit z triggerů CI zadáním trigger: none.

# A pipeline with no CI trigger
trigger: none

Důležité

Když nasdílíte změnu do větve, vyhodnocuje se soubor YAML v této větvi, aby zjistil, jestli se má spustit spuštění CI.

Klasické

Pokud chcete, aby se sestavení spustilo pokaždé, když někdo zkontroluje kód, vyberte Povolit kontinuální integraci na kartě Aktivační události .

Dávkové změny

Toto políčko zaškrtněte, pokud máte mnoho členů týmu, kteří často nahrávají změny a chcete snížit počet spuštěných sestavení. Pokud vyberete tuto možnost, když je sestavení spuštěné, systém počká, dokud se spuštění nedokončí, a pak zařadí další spuštění všech změn, které ještě nebyly sestaveny.

Změny můžete dávkovat a sestavovat je společně.

Poznámka:

Pokud používáte dávkování s kanálem YAML s vícefázovými fázemi, musí spuštění před spuštěním dosáhnout stavu terminálu. To není často žádoucí, protože kanál s více fázemi může projít schvalováním a dlouhotrvajícími fázemi nasazení. V těchto případech se doporučuje postupovat podle některého z těchto řešení:

• nepoužívejte dávkování
• rozdělení kanálu na dva samostatné kanály – jeden pro CI a jeden CD
• nastavení vhodných podmínek ve fázích, které je přeskočí, a rychlé ukončení spuštění

Filtry větví

Můžete zadat větve, ve kterých chcete aktivovat sestavení. Pokud chcete použít zástupné znaky, zadejte specifikaci větve (například features/modules/*) a stiskněte Enter.

Filtry cest

Pokud je vaše úložiště Git v Azure Repos nebo TFS, můžete také zadat filtry cest, které omezí sadu souborů, které chcete aktivovat sestavení.

Tipy:

• Cesty se vždy zadají vzhledem ke kořenovému adresáři úložiště.
• Pokud nenastavíte filtry cest, kořenová složka úložiště se implicitně zahrne do výchozího nastavení.
• Pokud cestu vyloučíte, nemůžete ji zahrnout ani v případě, že ji opravíte k hlubší složce. Pokud například vyloučíte /tools , můžete zahrnout /tools/trigger-runs-on-these
• Pořadífiltrůch
• Cesty v Gitu rozlišují malá a velká písmena. Nezapomeňte použít stejný případ jako skutečné složky.

Příklad

Například chcete, aby se vaše sestavení aktivovalo změnami ve main větvích funkcí, ale ne všechny. Nechcete také, aby se buildy aktivovaly změnami souborů ve složce nástrojů.

Přeskočení CI pro jednotlivé nabízení

Azure Pipelines také můžete říct, aby přeskočil spuštění kanálu, který by nabízená oznámení normálně aktivovala. Stačí zahrnout [skip ci] do zprávy nebo popisu všech potvrzení, která jsou součástí nabízeného oznámení, a Azure Pipelines přeskočí spuštění CI pro toto nabízení. Můžete také použít některou z následujících variant.

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

Použití typu triggeru v podmínkách

Běžným scénářem je spuštění různých kroků, úloh nebo fází v kanálu v závislosti na typu triggeru, který spuštění spustil. Můžete to provést pomocí systémové proměnné Build.Reason. Přidejte například do kroku, úlohy nebo fáze následující podmínku, abyste ji vyloučili z ověření žádostí o přijetí změn.

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

Chování triggerů při vytváření nových větví

Pro stejné úložiště je běžné nakonfigurovat více kanálů. Můžete mít například jeden kanál pro sestavení dokumentů pro vaši aplikaci a druhý pro sestavení zdrojového kódu. Triggery CI můžete nakonfigurovat s příslušnými filtry větví a filtry cest v každém z těchto kanálů. Můžete například chtít, aby se jeden kanál aktivoval, když odešlete aktualizaci do docs složky, a druhý kanál, který se aktivuje při nasdílení aktualizace kódu aplikace. V těchto případech je potřeba pochopit, jak se kanály aktivují při vytvoření nové větve.

Toto je chování při nasdílení nové větve (která odpovídá filtrům větví) do úložiště:

• Pokud váš kanál obsahuje filtry cest, aktivuje se pouze v případě, že nová větev obsahuje změny souborů, které odpovídají danému filtru cesty.
• Pokud váš kanál nemá filtry cest, aktivuje se i v případě, že nová větev neobsahuje žádné změny.

Zástupné znaky

Při zadávání větve, značky nebo cesty můžete použít přesný název nebo zástupný znak. Vzory se zástupnými znaky umožňují * shodovat s nulovými nebo více znaky a ? odpovídat jednomu znaku.

• Pokud začnete s vzorem * v kanálu YAML, musíte vzor zabalit do uvozovek, například "*-releases".
• Pro větve a značky:
  • Zástupný znak se může objevit kdekoli ve vzoru.
• Pro cesty:
  • V Azure DevOps Serveru 2022 a novějším, včetně Azure DevOps Services, se zástupný znak může objevit kdekoli v rámci vzoru cesty a můžete použít * nebo ?.
  • V Azure DevOps Serveru 2020 a nižším můžete jako konečný znak zahrnout * , ale nedělá nic jiného než zadání názvu adresáře samotným. Nesmíte být zahrnuti * doprostřed filtru cesty a možná nebudete používat ?.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Triggery žádosti o přijetí změn

Triggery žádosti o přijetí změn způsobují spuštění kanálu při každém otevření žádosti o přijetí změn nebo při nasdílení změn. V Gitu Azure Repos se tato funkce implementuje pomocí zásad větví. Pokud chcete povolit ověřování žádostí o přijetí změn, přejděte do zásad větve pro požadovanou větev a nakonfigurujte pro tuto větev zásady ověření sestavení. Další informace najdete v tématu Konfigurace zásad větve.

Pokud máte otevřenou žádost o přijetí změn a odešlete změny do zdrojové větve, může běžet několik kanálů:

• Kanály určené zásadou ověření sestavení cílové větve se spustí při potvrzení sloučení (sloučený kód mezi zdrojovými a cílovými větvemi žádosti o přijetí změn), bez ohledu na to, jestli existují nasdílené potvrzení, jejichž zprávy nebo popisy obsahují [skip ci] (nebo některé z jejích variant).
• Kanály aktivované změnami zdrojové větve žádosti o přijetí změn, pokud neexistují žádná nabízená potvrzení, jejichž zprávy nebo popisy obsahují [skip ci] (nebo některé z jejích variant). Pokud alespoň jedno nabízené potvrzení obsahuje [skip ci], kanály se nespustí.

Nakonec po sloučení žádosti o přijetí změn spustí Azure Pipelines kanály CI aktivované odesláním do cílové větve, a to i v případě, že některé zprávy nebo popisy sloučených potvrzení obsahují [skip ci] (nebo některé z jejích variant).

Poznámka:

Pokud chcete nakonfigurovat sestavení ověřování pro úložiště Git Azure Repos, musíte být správcem projektu.

Poznámka:

Koncepty žádostí o přijetí změn neaktivují kanál, ani když konfigurujete zásady větve.

Ověření příspěvků z forků

Vytváření žádostí o přijetí změn z forků Azure Repos se neliší od vytváření žádostí o přijetí změn v rámci stejného úložiště nebo projektu. Forky můžete vytvářet jenom ve stejné organizaci, ve které je projekt součástí.

Omezení rozsahu autorizace úlohy

Azure Pipelines poskytuje několik nastavení zabezpečení pro konfiguraci oboru autorizace úloh, se kterým vaše kanály běží.

• Omezení rozsahu autorizace úlohy na aktuální projekt
• Ochrana přístupu k úložištím v kanálech YAML

Omezení rozsahu autorizace úlohy na aktuální projekt

Azure Pipelines poskytuje dva rozsahy autorizace úloh limitu na aktuální nastavení projektu :

• Omezit rozsah autorizace úloh na aktuální projekt pro kanály bez verze – Toto nastavení platí pro kanály YAML a klasické kanály buildu. Toto nastavení se nevztahuje na klasické kanály verze.
• Omezit rozsah autorizace úloh na aktuální projekt pro kanály verze – Toto nastavení platí jenom pro klasické kanály verze.

Kanály se spouštějí s přístupovými tokeny s vymezeným kolekcí, pokud není povolené příslušné nastavení pro typ kanálu. Nastavení rozsahu omezení rozsahu autorizace úlohy umožňuje omezit rozsah přístupu pro všechny kanály do aktuálního projektu. To může mít vliv na váš kanál, pokud přistupujete k úložišti Git Azure Repos v jiném projektu ve vaší organizaci.

Pokud je úložiště Git Azure Repos v jiném projektu než váš kanál a je povolené nastavení rozsahu autorizace úlohy limitu pro váš typ kanálu, musíte udělit oprávnění identitě služby sestavení pro váš kanál druhému projektu. Další informace najdete v tématu Správa oprávnění účtu služby sestavení.

Další informace o omezení rozsahu autorizace úlohy najdete v tématu Vysvětlení přístupových tokenů úloh.

Ochrana přístupu k úložištím v kanálech YAML

Kanály mají přístup k libovolnému úložišti Azure DevOps v autorizovaných projektech, jak je popsáno v předchozím oboru autorizace úlohy Omezení na aktuální oddíl projektu , pokud není povolená ochrana přístupu k úložištím v kanálech YAML. Pokud je tato možnost povolená, můžete omezit rozsah přístupu pro všechny kanály pouze na úložiště Azure DevOps, na která se výslovně odkazuje checkout krok nebo uses příkaz v úloze kanálu, která toto úložiště používá.

Pokud chcete toto nastavení nakonfigurovat, přejděte na Kanály, nastavení v nastavení organizace nebo v nastavení projektu. Pokud je nastavení na úrovni organizace povolené, je nastavení neaktivní a není k dispozici na úrovni nastavení projektu.

Důležité

Ochrana přístupu k úložištím v kanálech YAML je ve výchozím nastavení povolená pro nové organizace a projekty vytvořené po květnu 2020. Pokud je povolená ochrana přístupu k úložištím v kanálech YAML, vaše kanály YAML musí explicitně odkazovat na všechna úložiště Git Azure Repos, která chcete v kanálu použít jako krok rezervace v úloze, která používá úložiště. Kód nebudete moct načíst pomocí skriptovacích úloh a příkazů Gitu pro úložiště Git Azure Repos, pokud na toto úložiště není poprvé explicitně odkazováno.

Existuje několik výjimek, kdy nemusíte explicitně odkazovat na úložiště Git Azure Repos, než ho použijete ve svém kanálu, když je povolená ochrana přístupu k úložištím v kanálech YAML.

• Pokud v kanálu nemáte explicitní krok rezervace, je to jako kdybyste měli checkout: self krok a self úložiště je rezervováno.
• Pokud k provádění operací jen pro čtení v úložišti ve veřejném projektu používáte skript, nemusíte v kroku odkazovat na úložiště checkout veřejného projektu.
• Pokud používáte skript, který poskytuje vlastní ověřování pro úložiště, například PAT, nemusíte odkazovat na toto úložiště v checkout kroku.

Pokud je například povolená ochrana přístupu k úložištím v kanálech YAML, pokud je váš kanál v FabrikamProject/Fabrikam úložišti ve vaší organizaci a chcete k pokladně FabrikamProject/FabrikamTools úložiště použít skript, musíte na toto úložiště odkazovat buď v checkout kroku, nebo pomocí uses příkazu.

Pokud už FabrikamTools registrujete úložiště ve svém kanálu pomocí kroku rezervace, můžete k interakci s tímto úložištěm následně použít skripty.

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

Poznámka:

V mnoha scénářích je možné využít rezervaci více úložišť a odebrat tak potřebu použití skriptů k rezervaci dalších úložišť ve vašem kanálu. Další informace najdete v tématu Rezervace více úložišť v kanálu.

Pokladna

Po aktivaci kanálu služba Azure Pipelines načte zdrojový kód z úložiště Git Azure Repos. Můžete řídit různé aspekty toho, jak se to stane.

Poznámka:

Když do kanálu zahrnete krok rezervace, spustíme následující příkaz: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Pokud to nevyhovuje vašim potřebám, můžete se rozhodnout vyloučit předdefinované rezervace checkout: none a pak pomocí úlohy skriptu provést vlastní rezervaci.

Upřednostňovaná verze Gitu

Agent Pro Windows se dodává s vlastní kopií Gitu. Pokud dáváte přednost vlastnímu Gitu místo použití zahrnuté kopie, nastavte na truehodnotu System.PreferGitFromPath . Toto nastavení platí vždy u agentů jiných než Windows.

Cesta k pokladně

YAML

Pokud si rezervujete jedno úložiště, ve výchozím nastavení se váš zdrojový kód rezervuje do adresáře s názvem s. U kanálů YAML to můžete změnit zadáním checkout parametru path. Zadaná cesta je relativní vzhledem k $(Agent.BuildDirectory). Příklad: Pokud je hodnota cesty rezervace a $(Agent.BuildDirectory) je mycustompath C:\agent\_work\1, zdrojový kód bude rezervován do C:\agent\_work\1\mycustompath.

Pokud používáte více checkout kroků a rezervování více úložišť a explicitně nezadáte složku pomocí path, každé úložiště se umístí do podsložky s pojmenované po úložišti. Pokud si například projdete dvě pojmenovaná tools úložiště a codezdrojový kód bude rezervován do C:\agent\_work\1\s\tools a C:\agent\_work\1\s\code.

Mějte na paměti, že hodnotu cesty rezervace nelze nastavit tak, aby přecházela na žádné úrovně adresáře výše $(Agent.BuildDirectory), takže path\..\anotherpath výsledkem bude platná cesta k pokladně (tj. C:\agent\_work\1\anotherpath), ale hodnota jako ..\invalidpath ne (tj. C:\agent\_work\invalidpath).

Nastavení můžete nakonfigurovat path v kroku Rezervace kanálu.

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

Klasické

Toto nastavení není v klasickém editoru konfigurovatelné. Váš zdrojový kód bude rezervován do adresáře s názvem s, který je relativní k $(Agent.BuildDirectory). Například: pokud $(Agent.BuildDirectory) je C:\agent\_work\1, bude zdrojový kód rezervován do C:\agent\_work\1\mycustompath.

Submoduly

YAML

Nastavení můžete nakonfigurovat submodules v kroku Rezervace kanálu, pokud chcete stahovat soubory z dílčích modulů.

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

Klasické

Pokud chcete stahovat soubory z dílčích modulů, můžete nakonfigurovat nastavení Submodules z vlastností úlohy Získat zdroje ve vašem kanálu.

Kanál buildu zkontroluje vaše dílčí režimy Gitu, pokud jsou:

• Neověřené: Veřejné neověřené úložiště bez přihlašovacích údajů potřebných ke klonování nebo načítání.

• Ověřený:

  • Obsažené ve stejném projektu jako úložiště Git Azure Repos uvedené výše. Stejné přihlašovací údaje, které agent používá k získání zdrojů z hlavního úložiště, slouží také k získání zdrojů pro dílčí moduly.

  • Přidáno pomocí adresy URL vzhledem k hlavnímu úložišti. Například

    • Toto by bylo rezervováno: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      V tomto příkladu dílčí modul odkazuje na úložiště (FabrikamFiber) ve stejné organizaci Azure DevOps, ale v jiném projektu (FabrikamFiberProject). Stejné přihlašovací údaje, které agent používá k získání zdrojů z hlavního úložiště, slouží také k získání zdrojů pro dílčí moduly. To vyžaduje, aby přístupový token úlohy měla přístup k úložišti v druhém projektu. Pokud jste omezili přístupový token úlohy, jak je vysvětleno v části výše, nebudete to moct udělat. Přístupový token úlohy můžete povolit přístup k úložišti v druhém projektu tak, že buď (a) explicitně udělíte přístup k účtu služby sestavení projektu v druhém projektu, nebo (b) pomocí přístupových tokenů v oboru kolekce místo tokenů v oboru projektu pro celou organizaci. Další informace o těchto možnostech a jejich dopadech na zabezpečení najdete v tématu Úložiště, artefakty a další prostředky Accessu.

    • Toto políčko by nebylo rezervováno: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternativu k použití možnosti Dílčí režimy rezervace

V některých případech nemůžete použít možnost Dílčí režimy rezervace. Může se stát, že pro přístup k dílčím modulům potřebujete jinou sadu přihlašovacích údajů. K tomu může dojít například v případě, že vaše hlavní úložiště a úložiště dílčího modulu nejsou uložená ve stejné organizaci Azure DevOps nebo pokud váš přístupový token úlohy nemá přístup k úložišti v jiném projektu.

Pokud nemůžete použít možnost Dílčí moduly rezervace, můžete místo toho k načtení dílčích modulů použít krok vlastního skriptu. Nejprve získejte osobní přístupový token (PAT) a předponu ho předponou pat:. Dále zakódujte tento řetězec s předponou base64 a vytvořte základní ověřovací token. Nakonec do kanálu přidejte tento skript:

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

Nezapomeňte nahradit "<BASE64_ENCODED_STRING>" řetězcem pat:token s kódováním Base64.

Pomocí proměnné tajného kódu v projektu nebo kanálu buildu uložte základní ověřovací token, který jste vygenerovali. Tuto proměnnou použijte k naplnění tajného kódu ve výše uvedeném příkazu Gitu.

Poznámka:

Otázka: Proč nemůžu v agentovi používat správce přihlašovacích údajů Gitu? A: Uložení přihlašovacích údajů dílčího modulu ve správci přihlašovacích údajů Gitu nainstalovaném v agentu privátního sestavení obvykle není efektivní, protože správce přihlašovacích údajů vás může vyzvat k opětovnému zadání přihlašovacích údajů při každé aktualizaci dílčího modulu. To není žádoucí během automatizovaných sestavení, pokud interakce uživatelů není možná.

Synchronizovat značky

Důležité

Funkce značek synchronizace se podporuje v Gitu Azure Repos s Azure DevOps Serverem 2022.1 a novějším.

Krok rezervace používá --tags možnost při načítání obsahu úložiště Git. To způsobí, že server načte všechny značky a všechny objekty, na které tyto značky odkazují. Tím se zvýší doba spuštění úlohy v kanálu, zejména pokud máte velké úložiště s řadou značek. Kromě toho krok rezervace synchronizuje značky i v případě, že povolíte možnost načtení mělké verze, a tím může porazit její účel. Aby se snížil objem načtených nebo načtených dat z úložiště Git, microsoft přidal novou možnost, která umožňuje kontrolu chování synchronizačních značek. Tato možnost je dostupná jak v klasických kanálech, tak v kanálech YAML.

Jestli se mají synchronizovat značky při rezervaci úložiště, je možné v YAML nakonfigurovat nastavením fetchTags vlastnosti a v uživatelském rozhraní konfigurací nastavení Značky synchronizace.

YAML

Nastavení můžete nakonfigurovat fetchTags v kroku Rezervace kanálu.

Chcete-li nakonfigurovat nastavení v YAML, nastavte fetchTags vlastnost.

steps:
- checkout: self
  fetchTags: true

Toto nastavení můžete také nakonfigurovat pomocí možnosti Synchronizovat značky v uživatelském rozhraní nastavení kanálu.

1. Upravte kanál YAML a zvolte Další akce, triggery.

   

2. Zvolte YAML, Získat zdroje.

   

3. Nakonfigurujte nastavení Synchronizovat značky.

   

Poznámka:

Pokud jste v checkout kroku explicitně nastavilifetchTags, má toto nastavení přednost před nastavením nakonfigurovaným v uživatelském rozhraní nastavení kanálu.

Klasické

Nastavení značek Synchronizace můžete nakonfigurovat z vlastností úlohy Získat zdroje ve vašem kanálu.

Výchozí chování

• U existujících kanálů vytvořených před vydáním sprintu Azure DevOps 209 vydaného v září 2022 zůstane výchozí synchronizace značek stejná jako stávající chování před přidáním možností značek synchronizace, což je true.
• Pro nové kanály vytvořené po verzi sprintu Azure DevOps 209 je falsevýchozím nastavením pro synchronizaci značek .

Poznámka:

Pokud jste v checkout kroku explicitně nastavilifetchTags, má toto nastavení přednost před nastavením nakonfigurovaným v uživatelském rozhraní nastavení kanálu.

Mělký fetch

Možná budete chtít omezit, jak daleko se má historie stáhnout. Výsledkem je git fetch --depth=nefektivně . Pokud je vaše úložiště velké, může tato možnost zefektivnit kanál buildu. Vaše úložiště může být velké, pokud se používá dlouhou dobu a má velikostelnou historii. Pokud jste přidali a později odstranili velké soubory, může to být také velké.

Důležité

Nové kanály vytvořené po aktualizaci sprintu Azure DevOps ze září 2022 mají ve výchozím nastavení povolenou funkci Mělké načtení a je nakonfigurované s hloubkou 1. Dříve se výchozí hodnota nenačítá. Pokud chcete zkontrolovat kanál, podívejte se do uživatelského rozhraní nastavení kanálu, jak je popsáno v následující části.

YAML

Nastavení můžete nakonfigurovat fetchDepth v kroku Rezervace kanálu.

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

Hloubku načítání můžete také nakonfigurovat nastavením možnosti Hloubková hloubka v uživatelském rozhraní nastavení kanálu.

1. Upravte kanál YAML a zvolte Další akce, triggery.

   

2. Zvolte YAML, Získat zdroje.

   

3. Nakonfigurujte nastavení načtení mělkých hodnot. Zrušte zaškrtnutí políčka Načíst mělký, pokud chcete zakázat mělké načítání, nebo zaškrtněte políčko a zadejte hloubku pro povolení mělkých načtení.

   

Poznámka:

Pokud jste v checkout kroku explicitně nastavilifetchDepth, má toto nastavení přednost před nastavením nakonfigurovaným v uživatelském rozhraní nastavení kanálu. Nastavení fetchDepth: 0 načte veškerou historii a přepíše nastavení pro načtení mělkých hodnot.

Klasické

Nastavení Pro načtení mělké hodnoty můžete nakonfigurovat z vlastností úlohy Získat zdroje ve vašem kanálu.

V těchto případech vám tato možnost může pomoct ušetřit síťové a úložné prostředky. Může také ušetřit čas. Důvodem, proč ne vždy šetří čas, je to proto, že v některých situacích může server potřebovat strávit čas výpočtem potvrzení ke stažení pro vámi určenou hloubku.

Poznámka:

Po spuštění kanálu se větev k sestavení přeloží na ID potvrzení. Potom agent načte větev a zkontroluje požadované potvrzení. Existuje malé okno mezi tím, kdy se větev přeloží na ID potvrzení a kdy agent provede rezervaci. Pokud se větev rychle aktualizuje a nastavíte velmi malou hodnotu pro mělké načtení, potvrzení nemusí existovat, když se agent pokusí ho rezervovat. Pokud k tomu dojde, zvyšte nastavení hloubky načtení mělké hloubky.

Nesynchronizovat zdroje

Možná budete chtít přeskočit načítání nových potvrzení. Tato možnost může být užitečná v případech, kdy chcete:

• Inicializaci, konfiguraci a načítání Gitu pomocí vlastních možností

• Pomocí kanálu buildu stačí spustit automatizaci (například některé skripty), které nezávisí na kódu ve správě verzí.

YAML

Nastavení Nesynchronizovat zdroje můžete nakonfigurovat v kroku Rezervace kanálu nastavením checkout: none.

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

Klasické

Ve vlastnostech úlohy Získat zdroje ve vašem kanálu vyberte nastavení Nesynchronizovat zdroje.

Poznámka:

Když použijete tuto možnost, agent také přeskočí spouštění příkazů Gitu, které vyčistí úložiště.

Vyčištění sestavení

Před spuštěním sestavení můžete provádět různé formy čištění pracovního adresáře agenta v místním prostředí.

Obecně platí, že pokud chcete dosáhnout rychlejšího výkonu agentů v místním prostředí, nevyčistíte úložiště. Pokud chcete dosáhnout nejlepšího výkonu, ujistěte se, že vytváříte také přírůstkově tím, že zakážete jakoukoli možnost vyčistit úlohu nebo nástroj, který používáte k sestavení.

Pokud potřebujete vyčistit úložiště (například předejít problémům způsobeným zbytkovými soubory z předchozího buildu), máte níže uvedené možnosti.

Poznámka:

Čištění není efektivní, pokud používáte agenta hostovaného Microsoftem, protože pokaždé získáte nového agenta.

YAML

Nastavení můžete nakonfigurovat clean v kroku Rezervace kanálu.

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

Je-li clean nastavena na true kanál sestavení provede vrácení zpět jakékoli změny v $(Build.SourcesDirectory). Konkrétně se před načtením zdroje spustí následující příkazy Gitu.

git clean -ffdx
git reset --hard HEAD

Další možnosti získáte tak, že nakonfigurujete workspace nastavení úlohy.

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

To poskytuje následující čisté možnosti.

• výstupy: Stejná operace jako čisté nastavení popsané v předchozí úloze rezervace a navíc: Odstraní a znovu vytvoří $(Build.BinariesDirectory). Mějte na paměti, že a $(Common.TestResultsDirectory) vždy se $(Build.ArtifactStagingDirectory) odstraní a znovu vytvoří před každým sestavením bez ohledu na toto nastavení.

• resources: Odstraní a znovu vytvoří $(Build.SourcesDirectory). Výsledkem je inicializace nového místního úložiště Git pro každé sestavení.

• all: Odstraní a znovu vytvoří $(Agent.BuildDirectory). Výsledkem je inicializace nového místního úložiště Git pro každé sestavení.

Klasické

Ve vlastnostech úlohy Získat zdroje v kanálu vyberte nastavení Vyčistit a vyberte jednu z následujících možností.

• Zdroje: Kanál buildu provede vrácení změn zpět v $(Build.SourcesDirectory)souboru . Konkrétně se před načtením zdroje spustí následující příkazy Gitu.

  git clean -ffdx
  git reset --hard HEAD
  

• Zdroje a výstupní adresář: Stejná operace jako výše uvedená možnost Zdroje plus: Odstraní a znovu vytvoří $(Build.BinariesDirectory). Mějte na paměti, že a $(Common.TestResultsDirectory) vždy se $(Build.ArtifactStagingDirectory) odstraní a znovu vytvoří před každým sestavením bez ohledu na toto nastavení.

• Adresář zdrojů: Odstraní a znovu vytvoří $(Build.SourcesDirectory). Výsledkem je inicializace nového místního úložiště Git pro každé sestavení.

• Všechny adresáře sestavení: Odstraní a znovu vytvoří $(Agent.BuildDirectory). Výsledkem je inicializace nového místního úložiště Git pro každé sestavení.

Zdroje popisků

Soubory zdrojového kódu můžete označovat tak, aby váš tým mohl snadno zjistit, která verze každého souboru je součástí dokončeného sestavení. Máte také možnost určit, jestli má být zdrojový kód označený pro všechna sestavení nebo pouze pro úspěšné sestavení.

YAML

Toto nastavení v YAML momentálně nejde nakonfigurovat, ale můžete ho použít v klasickém editoru. Při úpravě kanálu YAML máte přístup ke klasickému editoru tak, že v nabídce editoru YAML zvolíte aktivační události .

V klasickém editoru zvolte YAML, zvolte úlohu Získat zdroje a nakonfigurujte požadované vlastnosti tam.

Klasické

Nastavení Zdroje značek můžete nakonfigurovat z vlastností úlohy Získat zdroje ve vašem kanálu.

Ve formátu Značky můžete použít uživatelem definované a předdefinované proměnné, které mají obor "Vše". Například:

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

První čtyři proměnné jsou předdefinované. My.Variable můžete je definovat na kartě proměnných.

Kanál buildu označuje vaše zdroje značkou Git.

Některé proměnné sestavení můžou přinést hodnotu, která není platným popiskem. Například proměnné, například $(Build.RequestedFor) a $(Build.DefinitionName) mohou obsahovat prázdné znaky. Pokud hodnota obsahuje prázdné znaky, značka se nevytvořila.

Po označení zdrojů kanálem buildu se do dokončeného sestavení automaticky přidá artefakt s odkazem refs/tags/{tag} Git. Díky tomu může váš tým získat další sledovatelnost a uživatelsky přívětivější způsob, jak přejít z sestavení na vytvořený kód. Značka se považuje za artefakt sestavení, protože je vytvořen sestavením. Když se sestavení odstraní ručně nebo prostřednictvím zásad uchovávání informací, značka se odstraní také.

Často kladené dotazy

Problémy související s integrací Azure Repos spadají do tří kategorií:

• Triggery, které selhávají: Kanál se neaktivuje, když do úložiště nasdílím aktualizaci.
• Neúspěšná rezervace: Kanál se aktivuje, ale v kroku rezervace selže.
• Nesprávná verze: Kanál se spustí, ale používá neočekávanou verzi zdrojového nebo YAML.

Neúspěšné triggery

Právě jsem vytvořil nový kanál YAML s triggery CI/PR, ale kanál se neaktivuje.

Při řešení potíží se selháním triggerů postupujte následovně:

• Přepisují se triggery CI nebo PR YAML nastavením kanálu v uživatelském rozhraní? Při úpravě kanálu zvolte ... a pak Triggery.

  

  Zkontrolujte nastavení Přepsat trigger YAML odsud pro typy triggeru (kontinuální integrace nebo ověření žádosti o přijetí změn) dostupné pro vaše úložiště.

  

• Konfigurujete trigger žádosti o přijetí změn v souboru YAML nebo v zásadách větve pro úložiště? V případě úložiště Git v Azure Repos nemůžete v souboru YAML nakonfigurovat trigger žádosti o přijetí změn. Potřebujete použít zásady větve.

• Je kanál pozastavený nebo zakázaný? Otevřete editor kanálu a pak vyberte Nastavení , které chcete zkontrolovat. Pokud je kanál pozastavený nebo zakázaný, triggery nefungují.

• Aktualizovali jste soubor YAML ve správné větvi? Pokud odešlete aktualizaci do větve, pak soubor YAML ve stejné větvi řídí chování CI. Pokud odešlete aktualizaci do zdrojové větve, pak soubor YAML, který je výsledkem sloučení zdrojové větve s cílovou větví, řídí chování žádosti o přijetí změn. Ujistěte se, že soubor YAML ve správné větvi má potřebnou konfiguraci CI nebo PR.

• Nakonfigurovali jste trigger správně? Při definování triggeru YAML můžete zadat klauzule include i exclude pro větve, značky a cesty. Ujistěte se, že klauzule include odpovídá podrobnostem potvrzení a že je klauzule exclude nevyloučí. Zkontrolujte syntaxi triggerů a ujistěte se, že je přesná.

• Použili jste proměnné při definování triggeru nebo cest? To není podporováno.

• Použili jste šablony pro váš soubor YAML? Pokud ano, ujistěte se, že jsou triggery definované v hlavním souboru YAML. Triggery definované v souborech šablon se nepodporují.

• Vyloučili jste větve nebo cesty, do kterých jste změny odeslali? Otestujte vložením změny do zahrnuté cesty v zahrnuté větvi. Všimněte si, že cesty v triggerech rozlišují malá a velká písmena. Při zadávání cest v triggerech se ujistěte, že používáte stejný případ jako u skutečných složek.

• Právě jste nasdílili novou větev? Pokud ano, nová větev nemusí spustit nové spuštění. Viz část Chování triggerů při vytváření nových větví.

Triggery CI nebo PR fungují správně. Ale teď přestali pracovat.

Nejprve si projděte kroky pro řešení potíží v předchozí otázce. Pak postupujte podle těchto dalších kroků:

• Máte ve své žádosti o přijetí změn konflikty při slučování? V případě žádosti o přijetí změn, která neaktivovala kanál, otevřete ho a zkontrolujte, jestli došlo ke konfliktu při sloučení. Vyřešte konflikt při sloučení.

• Dochází ke zpoždění zpracování událostí nabízených oznámení nebo žádosti o přijetí změn? Obvykle to můžete ověřit tak, že zjistíte, jestli je problém specifický pro jeden kanál nebo je společný pro všechny kanály nebo úložiště v projektu. Pokud nabízené oznámení nebo aktualizace žádosti o přijetí změn do některého z úložišť tento příznak vykazuje, může docházet ke zpožděním při zpracování událostí aktualizace. Zkontrolujte, jestli na naší stránce stavu nedochází k výpadku služby. Pokud se na stránce stavu zobrazí problém, musí na ní náš tým už začít pracovat. Podívejte se na stránku, kde najdete časté aktualizace problému.

Nechci, aby uživatelé při aktualizaci souboru YAML přepsali seznam větví pro triggery. Jak mám postupovat?

Uživatelé s oprávněními k přispívání kódu mohou aktualizovat soubor YAML a zahrnout nebo vyloučit další větve. V důsledku toho můžou uživatelé do souboru YAML zahrnout vlastní funkci nebo větev uživatele a odeslat aktualizaci do funkce nebo větve uživatele. To může způsobit aktivaci kanálu pro všechny aktualizace této větve. Pokud chcete tomuto chování zabránit, můžete:

1. Upravte kanál v uživatelském rozhraní Azure Pipelines.
2. Přejděte do nabídky Aktivační události .
3. Tady vyberte Přepsat trigger kontinuální integrace YAML.
4. Zadejte větve, které se mají zahrnout nebo vyloučit pro trigger.

Když budete postupovat podle těchto kroků, budou všechny triggery CI zadané v souboru YAML ignorovány.

V kanálu YAML mám více úložišť. Jak můžu nastavit triggery pro jednotlivá úložiště?

Projděte si část Triggery v tématu věnovaném používání více úložišť.

Neúspěšná rezervace

Během kroku rezervace se v souboru protokolu zobrazuje následující chyba. Jak to můžu vyřešit?

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

Při řešení potíží s neúspěšnou kontrolou postupujte následovně:

• Existuje úložiště stále? Nejdřív se ujistěte, že to funguje tak, že ho otevřete na stránce Úložiště .

• Přistupujete k úložišti pomocí skriptu? Pokud ano, zkontrolujte rozsah autorizace úlohy limitu odkazovaného na nastavení úložiště Azure DevOps. Pokud je povolený limit rozsahu autorizace úloh na odkazovaná úložiště Azure DevOps, nebudete moct rezervovat úložiště Git Azure Repos pomocí skriptu, pokud nejsou explicitně odkazovány jako první v kanálu.

• Jaký je rozsah autorizace úlohy kanálu?

  • Pokud je obor kolekce:

    • Může se jednat o občasnou chybu. Znovu spusťte kanál.
    • Někdo možná odebral přístup k účtu služby sestavení kolekce projektů.
      • Přejděte do nastavení projectu pro projekt, ve kterém úložiště existuje. Vyberte úložiště repos > > specifická pro úložiště a pak zabezpečení.
      • Zkontrolujte, jestli v seznamu uživatelů existuje služba sestavení kolekce projektů (název kolekce).
      • Zkontrolujte, jestli má tento účet značku Vytvořit a Přístup pro čtení .

  • Pokud je obor projekt:

    • Je úložiště ve stejném projektu jako kanál?
      • Ano:
        • Může se jednat o občasnou chybu. Znovu spusťte kanál.
        • Někdo možná odebral přístup k účtu služby Sestavení projektu.
          • Přejděte do nastavení projectu pro projekt, ve kterém úložiště existuje. Vyberte úložiště repos > > specifická pro úložiště a pak zabezpečení.
          • Zkontrolujte, jestli v seznamu uživatelů existuje služba buildu s názvem vašeho projektu (název_kolekce).</a0>
          • Zkontrolujte, jestli má tento účet značku Vytvořit a Přístup pro čtení .
      • Ne:
        • Je váš kanál ve veřejném projektu?
          • Ano: Nemůžete získat přístup k prostředkům mimo veřejný projekt. Nastavit projekt jako soukromý
          • Ne: Musíte nakonfigurovat oprávnění pro přístup k jinému úložišti ve stejné kolekci projektů.

Nesprávná verze

V kanálu se používá nesprávná verze souboru YAML. Proč?

• U triggerů CI se vyhodnocuje soubor YAML, který je ve větvi, kterou odesíláte, a zjistí, jestli se má spustit sestavení CI.
• U triggerů žádosti o přijetí změn se soubor YAML, který je výsledkem sloučení zdrojových a cílových větví žádosti o přijetí změn, vyhodnocuje, jestli se má spustit sestavení žádosti o přijetí změn.

Související články

• Plánované triggery
• Triggery dokončení kanálu