Možnosti kanálu pro úložiště Git

  • Článek

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

Při úpravách kanálu, který používá úložiště Git – v projektu Azure DevOps, GitHubu, GitHubu Enterprise Serveru, Bitbucket Cloudu nebo jiném úložišti Git máte následující možnosti.

Funkce Azure Pipelines Azure DevOps Server 2019 a novější TFS 2018
Pobočka Ano Ano Yes
Clean Ano Ano Yes
Zdroje značek nebo popisků Projektu; Pouze classic Týmový projekt Týmový projekt
Sestava stavu sestavení Ano Ano Yes
Rezervace dílčích modulů Ano Ano Yes
Rezervace souborů z LFS Ano Ano Yes
Klonování druhého úložiště Ano Ano Yes
Nesynchronizovat zdroje Ano Ano Yes
Mělký fetch Ano Ano Ano

Poznámka:

Kliknutím na Upřesnit nastavení v úloze Získat zdroje zobrazíte některé z výše uvedených možností.

Pobočka

Toto je větev, kterou chcete nastavit jako výchozí, když ručně zařadíte tento build do fronty. Pokud nastavíte naplánovanou aktivační událost pro sestavení, jedná se o větev, ze které bude vaše sestavení získávat nejnovější zdroje. Výchozí větev nemá žádné ložisko při aktivaci sestavení prostřednictvím kontinuální integrace (CI). Obvykle to nastavíte tak, aby byla stejná jako výchozí větev úložiště (například "master").

Vyčištění místního úložiště v agentu

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. Pokud používáte agenty v místním prostředí v závislosti na konfiguraci fondů agentů, můžete získat nového agenta pro následné spuštění kanálu (nebo fáze nebo úlohy ve stejném kanálu), takže nezaručíte čištění, že následné spuštění, úlohy nebo fáze budou mít přístup k výstupům z předchozích spuštění, úloh nebo fází.

Poznámka:

Pokud používáte agenty v místním prostředí v závislosti na konfiguraci fondů agentů, můžete získat nového agenta pro následné spuštění kanálu (nebo fáze nebo úlohy ve stejném kanálu), takže nezaručíte čištění, že následné spuštění, úlohy nebo fáze budou mít přístup k výstupům z předchozích spuštění, úloh nebo fází. Artefakty sestavení můžete použít ke sdílení výstupů spuštění, fáze nebo úlohy kanálu s následnými spuštěními, fázemi nebo úlohami.

Azure Pipelines, Azure DevOps Server 2019 a novější

Pro kanály YAML je k dispozici několik různých možností čištění.

  • Krok checkout má clean možnost. Pokud je truetato možnost nastavená, kanál se spustí execute git clean -ffdx && git reset --hard HEAD před načtením úložiště. Další informace najdete v tématu Rezervace.
  • Nastavení workspace má job několik možností čištění (výstupy, prostředky, vše). Další informace najdete v tématu Pracovní prostor.
  • Uživatelské rozhraní nastavení kanálu má nastavení Vyčistit , které při nastavení na hodnotu true odpovídá zadání clean: true pro každý checkout krok v kanálu. Konfigurace nastavení Vyčistit:

    1. Upravte kanál, zvolte ...a vyberte Aktivační události.

      Úpravy aktivačních událostí

    2. Vyberte YAML, Získat zdroje a nakonfigurujte požadované nastavení Vyčistit . Výchozí hodnota je true.

      Čisté nastavení.

Pokud chcete přepsat čistá nastavení při ručním spuštění kanálu, můžete použít parametry modulu runtime. V následujícím příkladu se k konfiguraci čistého nastavení rezervace používá parametr modulu runtime.

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

Ve výchozím nastavení je nastavená na true hodnotu, clean ale při ručním spuštění kanálu můžete přepsat zaškrtnutím políčka Checkout clean checkout, které je přidáno pro parametr modulu runtime.

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

Poznámka:

Tuto funkci můžete použít jenom v případě, že zdrojové úložiště ve vašem buildu je úložiště GitHub nebo úložiště Git nebo TFVC z vašeho projektu.

Ve formátu Popisek můžete použít uživatelem definované a předdefinované proměnné, které mají obor "Vše". Pří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é.

Hlášení stavu sestavení (Azure Pipelines, TFS 2018 a novější)

Máte možnost dát týmu zobrazení stavu sestavení ze vzdáleného zdrojového úložiště.

Pokud jsou vaše zdroje v úložišti Git Azure Repos ve vašem projektu, zobrazí tato možnost na stránce Kód odznáček, který indikuje, jestli se sestavení předává nebo selhává. Stav sestavení se zobrazí na následujících kartách:

  • Soubory: Označuje stav nejnovějšího sestavení pro vybranou větev.
  • Potvrzení: Označuje stav sestavení každého potvrzení (to vyžaduje povolení triggeru kontinuální integrace (CI) pro vaše sestavení).
  • Větve: Označuje stav nejnovějšího sestavení pro každou větev.

Pokud ve svém projektu používáte více kanálů sestavení pro stejné úložiště, můžete tuto možnost povolit pro jeden nebo více kanálů. V případě, že je tato možnost povolená u více kanálů, odznáček na stránce Kód označuje stav nejnovějšího buildu ve všech kanálech. Členové vašeho týmu můžou kliknout na odznáček stavu sestavení a zobrazit nejnovější stav sestavení pro každý kanál buildu.

GitHubu

Pokud jsou vaše zdroje na GitHubu, tato možnost publikuje stav sestavení na GitHub pomocí rozhraní GITHub Checks nebo Status API. Pokud se sestavení aktivuje z žádosti o přijetí změn GitHubu, můžete zobrazit stav na stránce žádosti o přijetí změn Na GitHubu. To vám také umožňuje nastavit zásady stavu v Rámci GitHubu a automatizovat sloučení. Pokud je sestavení aktivované kontinuální integrací (CI), můžete zobrazit stav sestavení na potvrzení nebo větvi na GitHubu.

Další typy vzdálených úložišť Git

Pokud je váš zdroj v jiném typu vzdáleného úložiště, nemůžete k automatickému publikování stavu sestavení do tohoto úložiště použít Azure Pipelines ani TFS. Odznáček buildu ale můžete použít jako způsob integrace a zobrazení stavu sestavení v rámci prostředí správy verzí.

Cesta k pokladně

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 mycustompathC:\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).

Pokud používáte více checkout kroků a rezervování více úložišť a chcete explicitně zadat složku pomocí path, zvažte možnost vyhnout se nastavení cesty, která je podsložka cesty jiného kroku rezervace (tj. C:\agent\_work\1\s\repo1 a C:\agent\_work\1\s\repo1\repo2), jinak se podsložka kroku rezervace vymaže čištěním jiného úložiště. Upozorňujeme, že tento případ je platný, pokud platí čistá možnost pro repo1)

Poznámka:

Cestu k pokladně je možné zadat pouze pro kanály YAML. Další informace najdete v tématu Rezervace ve schématu YAML.

Rezervační dílčí moduly

Vyberte, jestli chcete stahovat soubory z dílčích modulů. Můžete se rozhodnout buď získat okamžité dílčímoduly, nebo všechny dílčímoduly vnořené do jakékoli hloubky rekurze. Pokud chcete používat LFS s dílčími režimy, nezapomeňte si prohlédnout poznámku o použití LFS s dílčími režimy.

Poznámka:

Další informace o syntaxi YAML pro rezervaci dílčích modulů naleznete v tématu Rezervace ve schématu YAML.

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, organizaci GitHubu nebo účtu Bitbucket Cloud jako úložiště Git uvedené výše.

    • Přidáno pomocí adresy URL vzhledem k hlavnímu úložišti. Například tato by byla rezervována: git submodule add /../../submodule.git mymodule Tato by nebyla rezervována: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Ověřené dílčímoduly

Poznámka:

Ujistěte se, že jste své dílčímoduly zaregistrovali pomocí protokolu HTTPS a nepoužíváte SSH.

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.

Pokud se hlavní úložiště a dílčí moduly nacházejí v úložišti Git Azure Repos v projektu Azure DevOps, můžete vybrat účet použitý pro přístup ke zdrojům. Na kartě Možnosti vyberte v nabídce Rozsah autorizace úlohy sestavení jednu z těchto možností:

  • Kolekce projektů pro použití účtu služby Sestavení kolekce projektů

  • Aktuální projekt pro použití účtu služby Sestavení projektu

Ujistěte se, že jakýkoli účet, který používáte, má přístup k hlavnímu úložišti i k dílčím modulům.

Pokud jsou hlavní úložiště a dílčí moduly ve stejné organizaci GitHubu, použije se token uložený v připojení ke službě GitHub pro přístup ke zdrojům.

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 ve službě Git.

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

Nezapomeňte nahradit "<BASIC_AUTH_TOKEN>" tokenem 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á.

Rezervace souborů z LFS

Vyberte, jestli chcete stahovat soubory z velkého úložiště souborů (LFS).

V klasickém editoru zaškrtněte políčko, pokud chcete tuto možnost povolit.

V sestavení YAML přidejte krok rezervace s nastaveným lfs na true:

steps:
- checkout: self
  lfs: true

Pokud používáte TFS nebo používáte Azure Pipelines s místním agentem, musíte na agenta nainstalovat git-lfs , aby tato možnost fungovala. Pokud hostovaní agenti používají Windows, zvažte použití System.PreferGitFromPath proměnné, abyste zajistili, že kanály používají verze Gitu a git-lfs, které jste nainstalovali na počítač. Další informace najdete v tématu Jakou verzi Gitu můj agent spouští?

Použití Git LFS s dílčími režimy

Pokud dílčí modul obsahuje soubory LFS, musí být před rezervování dílčích modulů nakonfigurovaný Git LFS. Agenti macOS a Linux hostovaní Microsoftem jsou tímto způsobem předem nakonfigurovaní. Agenti Windows a agenti macOS nebo Linux v místním prostředí nemusí.

Pokud používáte YAML, můžete jako alternativní řešení přidat následující krok před:checkout

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Klonování druhého úložiště

Ve výchozím nastavení je váš kanál přidružený k jednomu úložišti z Azure Repos nebo externího poskytovatele. Toto je úložiště, které může aktivovat sestavení na potvrzeních a žádostech o přijetí změn.

Do kanálu můžete zahrnout zdroje z druhého úložiště. Můžete to provést napsáním skriptu.

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

Pokud úložiště není veřejné, budete muset předat ověření do příkazu Git.

Azure Repos

Váš kanál už bude mít přístup k jiným úložišťm v projektu a můžete je v kanálu naklonovat pomocí příkazu skriptu, jak je znázorněno v následujícím příkladu.

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

Pokud potřebujete naklonovat úložiště z jiného projektu, který není veřejný, budete se muset ověřit jako uživatel, který má k danému projektu přístup.

Poznámka:

K bezpečnému uložení přihlašovacích údajů použijte proměnnou tajného kódu.

Tajné proměnné nejsou automaticky zpřístupněny skriptům jako proměnné prostředí. Informace o tom, jak je mapovat, najdete v tématu Tajné proměnné .

Pro Azure Repos můžete použít osobní přístupový token s oprávněním Code (Read). Odešlete toto pole jako heslo v hlavičce základní autorizace bez uživatelského jména. (Jinými slovy, base64 kóduje hodnotu :<PAT>, včetně dvojtečky.)

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

Nesynchronizovat zdroje

Úlohy bez nasazení automaticky načítají zdroje. Tuto možnost použijte, pokud chcete toto chování přeskočit. 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í.

Pokud chcete zakázat stahování zdrojů:

  • Azure Pipelines, TFS 2018 a novější: Klikněte na Upřesnit nastavení a pak vyberte 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ě.

Mělký fetch

Vyberte, jestli chcete 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é.

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:

Když je sestavení zařazeno do fronty, větev k sestavení se 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.

Po zaškrtnutí políčka pro povolení této možnosti zadejte v poli Hloubka počet potvrzení.

Tip

Proměnná Agent.Source.Git.ShallowFetchDepth uvedená níže také funguje a přepíše ovládací prvky zaškrtávacího políčka. Tímto způsobem můžete změnit nastavení při zařadíte do fronty sestavení.

Preferovat Git z cesty

Ve výchozím nastavení používá agent Windows verzi Gitu, která je součástí softwaru agenta. Microsoft doporučuje používat verzi Gitu, která je součástí agenta, ale máte několik možností, jak toto výchozí chování přepsat a použít verzi Gitu, kterou má počítač agenta nainstalovaný v cestě.

Pokud chcete zobrazit verzi Gitu používanou kanálem, můžete se podívat na protokoly kroku checkout v kanálu, jak je znázorněno v následujícím příkladu.

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

Toto nastavení platí vždy u agentů jiných než Windows.

Možnosti triggeru pro jiný Git

Pokud je zadané jiné nebo externí úložiště Git, sestavení CI vyžadují, aby bylo úložiště přístupné z internetu. Pokud se úložiště nachází za bránou firewall nebo proxy serverem, bude fungovat pouze naplánované a ruční sestavení.

Často kladené dotazy

Jaké protokoly může agent sestavení používat s Gitem?

Agent podporuje PROTOKOL HTTPS.

Agent zatím nepodporuje SSH. Viz Povolit sestavení používat ověřování SSH při rezervaci dílčích modulů Gitu.

Používám místně TFS a některé z těchto funkcí nevidím. Proč ne?

Některé z těchto funkcí jsou dostupné jenom v Azure Pipelines a zatím nejsou dostupné místně. Některé funkce jsou dostupné místně, pokud jste upgradovali na nejnovější verzi TFS.