Sdílet prostřednictvím

Vytváření úložišť GitHub

  • Článek

azure DevOps Services

Azure Pipelines může automaticky sestavovat a ověřovat všechny žádosti o přijetí změn a potvrdit je do vašeho úložiště GitHub. Tento článek popisuje, jak nakonfigurovat integraci mezi GitHubem a Azure Pipelines.

Pokud s integrací kanálů s GitHubem teprve začínáte, postupujte podle kroků v Vytvoření prvního kanálu. Vraťte se k tomuto článku a získejte další informace o konfiguraci a přizpůsobení integrace mezi GitHubem a Azure Pipelines.

Organizace a uživatelé

GitHub a Azure Pipelines jsou dvě nezávislé služby, které se dobře integrují. Každý z nich má vlastní organizaci a správu uživatelů. Tato část obsahuje doporučení, jak replikovat organizaci a uživatele z GitHubu do Azure Pipelines.

Organizace

Struktura GitHubu se skládá z organizací a uživatelských účtů, které obsahují úložiště . Viz dokumentaci k GitHubu.

organizační struktury GitHubu

Struktura Azure DevOps se skládá z organizací, které obsahují projekty. Viz Plánování organizační struktury.

organizační struktury Azure DevOps

Azure DevOps může odrážet strukturu GitHubu pomocí:

  • Organizace DevOps pro organizaci GitHubu nebo uživatelského účtu
  • Projekty DevOps pro úložiště GitHubu

struktura GitHubu namapovaná na Azure DevOps

Nastavení stejné struktury v Azure DevOps:

  1. Vytvořte organizaci DevOps pojmenovanou po vaší organizaci nebo uživatelském účtu GitHubu. Bude mít adresu URL jako https://dev.azure.com/your-organization.
  2. V organizaci DevOps vytvořte projekty pojmenované po úložištích. Budou mít adresy URL jako https://dev.azure.com/your-organization/your-repository.
  3. V projektu DevOps vytvořte kanály pojmenované podle organizace GitHubu a úložiště, které sestavují, například your-organization.your-repository. Pak je jasné, pro která úložiště jsou určená.

Po tomto vzoru budou mít vaše úložiště GitHubu a Azure DevOps Projects odpovídající cesty url. Například:

Služba Adresa URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Uživatelé

Uživatelé GitHubu automaticky nezískají přístup ke službě Azure Pipelines. Azure Pipelines neví o identitách GitHubu. Z tohoto důvodu neexistuje způsob, jak nakonfigurovat Azure Pipelines tak, aby automaticky upozorňovat uživatele na selhání sestavení nebo na selhání ověření žádosti o přijetí změn pomocí identity a e-mailové adresy GitHubu. Abyste mohli replikovat uživatele GitHubu, musíte v Azure Pipelines explicitně vytvářet nové uživatele. Po vytvoření nových uživatelů můžete v Azure DevOps nakonfigurovat jejich oprávnění tak, aby odrážela jejich oprávnění na GitHubu. Oznámení v DevOps můžete také nakonfigurovat pomocí jejich identity DevOps.

Role organizace GitHubu

Členské role organizace GitHubu najdete v https://github.com/orgs/your-organization/people (nahraďte your-organization).

Oprávnění členů organizace DevOps najdete v https://dev.azure.com/your-organization/_settings/security (nahraďte your-organization).

Role v organizaci GitHubu a ekvivalentní role v organizaci Azure DevOps jsou uvedené níže.

Role organizace GitHubu Ekvivalent organizace DevOps
Vlastník Člen Project Collection Administrators
Správce fakturace Člen Project Collection Administrators
Člen Člen Project Collection Valid Users. Ve výchozím nastavení nemá členová skupina oprávnění k vytváření nových projektů. Pokud chcete oprávnění změnit, nastavte oprávnění skupiny Create new projects na Allownebo vytvořte novou skupinu s potřebnými oprávněními.

Role uživatelského účtu GitHubu

Uživatelský účet GitHubu má jednu roli, což je vlastnictví účtu.

Oprávnění členů organizace DevOps najdete v https://dev.azure.com/your-organization/_settings/security (nahraďte your-organization).

Role uživatelského účtu GitHubu se mapuje na oprávnění organizace DevOps následujícím způsobem.

Role uživatelského účtu GitHubu Ekvivalent organizace DevOps
Vlastník Člen Project Collection Administrators

Oprávnění úložiště GitHub

Oprávnění k úložišti GitHub najdete v https://github.com/your-organization/your-repository/settings/collaboration (nahraďte your-organization a your-repository).

Oprávnění projektu DevOps najdete v https://dev.azure.com/your-organization/your-project/_settings/security (nahraďte your-organization a your-project).

Ekvivalentní oprávnění mezi úložišti GitHub a Azure DevOps Projects jsou následující.

Oprávnění úložiště GitHub Ekvivalent projektu DevOps
Admin Člen Project Administrators
Psát Člen Contributors
Číst Člen Readers

Pokud vaše úložiště GitHubu uděluje oprávnění týmům, můžete vytvořit odpovídající týmy v části Teams nastavení projektu Azure DevOps. Potom přidejte týmy do výše uvedených skupin zabezpečení, stejně jako uživatelé.

Oprávnění specifická pro kanály

Pokud chcete uživatelům nebo týmům udělit oprávnění pro konkrétní kanály v projektu DevOps, postupujte takto:

  1. Navštivte stránku Kanálů projektu (například https://dev.azure.com/your-organization/your-project/_build).
  2. Vyberte kanál, pro který chcete nastavit konkrétní oprávnění.
  3. V místní nabídce...vyberte Security.
  4. Vyberte Přidat... přidání konkrétního uživatele, týmu nebo skupiny a přizpůsobení jejich oprávnění pro kanál.

Přístup k úložištím GitHub

  • YAML
  • Classic

Nový kanál vytvoříte tak, že nejprve vyberete úložiště GitHub 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ě více úložiští.

Azure Pipelines musí mít udělený přístup k vašim úložištím, aby se aktivovaly jejich buildy, a načíst kód během sestavení.

Existují tři typy ověřování pro udělení přístupu azure Pipelines k úložištím GitHubu při vytváření kanálu.

Typ ověřování Kanály se spouštějí pomocí Funguje s GitHub Checks
1. aplikace GitHubu Identita Azure Pipelines Ano
2. OAuth Vaše osobní identita GitHubu Ne
3. pat přístupový token (PAT) Vaše osobní identita GitHubu Ne

Ověřování aplikací GitHubu

Aplikace Azure Pipelines na GitHubu je doporučený typ ověřování pro kanály kontinuální integrace. Po instalaci aplikace GitHub v účtu nebo organizaci GitHubu se kanál spustí bez použití vaší osobní identity GitHubu. Aktualizace stavu buildů a GitHubu se provádějí pomocí identity Azure Pipelines. Aplikace funguje s GitHub Checks k zobrazení výsledků pokrytí sestavení, testování a kódu na GitHubu.

Pokud chcete používat aplikaci GitHub, nainstalujte ji do organizace GitHubu nebo uživatelského účtu pro některá nebo všechna úložiště. Aplikaci GitHub je možné nainstalovat a odinstalovat z domovské stránky aplikace .

Po instalaci se aplikace GitHub stane výchozí metodou ověřování Azure Pipelines na GitHubu (místo OAuth), když se pro úložiště vytvoří kanály.

Pokud nainstalujete aplikaci GitHub pro všechna úložiště v organizaci GitHubu, nemusíte si dělat starosti s odesíláním hromadných e-mailů nebo automatickým nastavením kanálů vaším jménem. Pokud je ale aplikace nainstalovaná pro všechna úložiště, token používaný aplikací bude mít přístup ke všem úložištím, včetně privátních. Z bezpečnostních důvodů se doporučuje oddělit privátní a veřejná úložiště na úrovni organizace. To znamená, že mít vyhrazenou organizaci pouze pro veřejné projekty bez privátních úložišť. Pokud je z nějakého důvodu potřeba mít ve stejné organizaci veřejná a privátní úložiště, místo použití přístupu pro všechna úložiště explicitně vyberte úložiště, ke kterým by měla aplikace mít přístup. To vyžaduje více práce pro správce, ale zajišťuje lepší správu zabezpečení.

Oprávnění potřebná v GitHubu

Instalace aplikace Azure Pipelines Na GitHubu vyžaduje, abyste byl vlastníkem organizace Nebo správcem úložiště GitHubu. Pokud chcete vytvořit kanál pro úložiště GitHub s průběžnou integrací a triggery žádostí o přijetí změn, musíte mít nakonfigurovaná požadovaná oprávnění GitHubu. V opačném případě se úložiště při vytváření kanálu nezobrazí v seznamu úložišť. V závislosti na typu ověřování a vlastnictví úložiště se ujistěte, že je nakonfigurovaný odpovídající přístup.

  • Pokud je úložiště ve vašem osobním účtu GitHubu, nainstalujte si aplikaci Azure Pipelines GitHub do svého osobního účtu GitHubu a při vytváření kanálu v Azure Pipelines budete moct toto úložiště vypsat.

  • Pokud je úložiště v osobním účtu GitHubu někoho jiného, musí si druhý uživatel nainstalovat aplikaci GitHub Azure Pipelines do svého osobního účtu GitHubu. Musíte být přidáni jako spolupracovník v nastavení úložiště v části Spolupracovníci. Přijměte pozvánku jako spolupracovníka pomocí odkazu, který vám pošle e-mail. Jakmile to uděláte, můžete pro toto úložiště vytvořit kanál.

  • Pokud je úložiště v organizaci GitHubu, kterou vlastníte, nainstalujte aplikaci Azure Pipelines GitHub v organizaci GitHubu. Musíte být také přidáni jako spolupracovník nebo musí být přidán váš tým v nastavení úložiště v části Spolupracovníci a týmy.

  • Pokud je úložiště v organizaci GitHubu, kterou vlastní někdo jiný, musí vlastník organizace Nebo správce úložiště GitHubu nainstalovat aplikaci Azure Pipelines GitHub v organizaci. Musíte být přidáni jako spolupracovník nebo musíte přidat váš tým v nastavení úložiště v části Spolupracovníci a týmy. Přijměte pozvánku jako spolupracovníka pomocí odkazu, který vám pošle e-mail.

Oprávnění aplikace GitHubu

Aplikace GitHub během instalace vyžaduje následující oprávnění:

Povolení Jak Azure Pipelines používá oprávnění
Zápis přístupu k kódu Pouze při záměrné akci azure Pipelines zjednoduší vytvoření kanálu tím, že potvrdí soubor YAML do vybrané větve vašeho úložiště GitHub.
Přístup pro čtení k metadatům Azure Pipelines načte metadata GitHubu pro zobrazení úložiště, větví a problémů souvisejících s sestavením v souhrnu sestavení.
Přístup ke čtení a zápisu pro kontroly Azure Pipelines bude číst a zapisovat vlastní výsledky sestavení, testování a pokrytí kódu, které se mají zobrazit na GitHubu.
Přístup pro čtení a zápis k žádostem o přijetí změn Pouze při záměrné akci azure Pipelines zjednoduší vytvoření kanálu vytvořením žádosti o přijetí změn pro soubor YAML, který byl potvrzen do vybrané větve vašeho úložiště GitHub. Kanály načítají metadata žádostí, která se zobrazí v souhrnech sestavení přidružených k žádostem o přijetí změn.

Řešení potíží s instalací aplikace GitHub

GitHub může zobrazit chybu, například:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

To znamená, že aplikace GitHub už je pravděpodobně nainstalovaná pro vaši organizaci. Když vytvoříte kanál pro úložiště v organizaci, aplikace GitHub se automaticky použije pro připojení k GitHubu.

Vytváření kanálů v několika organizacích a projektech Azure DevOps

Po instalaci aplikace GitHub je možné kanály vytvořit pro úložiště organizace v různých organizacích a projektech Azure DevOps. Pokud ale vytváříte kanály pro jedno úložiště v několika organizacích Azure DevOps, dají se automaticky aktivovat jenom kanály první organizace pomocí potvrzení GitHubu nebo žádostí o přijetí změn. Ruční nebo plánované buildy jsou stále možné v sekundárních organizacích Azure DevOps.

Ověřování OAuth

OAuth je nejjednodušší typ ověřování, se kterým můžete začít pracovat pro úložiště ve vašem osobním účtu GitHubu. Aktualizace stavu GitHubu se provádějí jménem vaší osobní identity GitHubu. Aby kanály dál fungovaly, musí mít přístup k úložišti stále aktivní. Některé funkce GitHubu, jako jsou Kontroly, nejsou u OAuth dostupné a vyžadují aplikaci GitHub.

Pokud chcete použít OAuth, vyberte Zvolte jiné připojení pod seznamem úložišť při vytváření kanálu. Pak vyberte Autorizovat, abyste se přihlásili k GitHubu a autorizovali pomocí OAuth. Připojení OAuth se uloží do projektu Azure DevOps pro pozdější použití a použije se v kanálu, který se vytváří.

Oprávnění potřebná v GitHubu

Pokud chcete vytvořit kanál pro úložiště GitHub s průběžnou integrací a triggery žádostí o přijetí změn, musíte mít nakonfigurovaná požadovaná oprávnění GitHubu. V opačném případě se úložiště při vytváření kanálu nezobrazí v seznamu úložišť. V závislosti na typu ověřování a vlastnictví úložiště se ujistěte, že je nakonfigurovaný odpovídající přístup.

  • Pokud je úložiště ve vašem osobním účtu GitHubu, alespoň jednou se pomocí OAuth ověřte na GitHubu pomocí svých osobních přihlašovacích údajů k účtu GitHub. To je možné provést v nastavení projektu Azure DevOps v části Připojení služby Pipelines > Service > Nové připojení služby > GitHub > Authorize. Udělte službě Azure Pipelines přístup k vašim úložištím v části Oprávnění tady.

  • Pokud je úložiště v osobním účtu GitHubu někoho jiného, aspoň jednou, musí se druhý uživatel ověřit na GitHubu pomocí OAuth pomocí svých osobních přihlašovacích údajů k účtu GitHub. To je možné provést v nastavení projektu Azure DevOps v části Připojení služby Pipelines > Service > Nové připojení služby > GitHub > Authorize. Druhý uživatel musí službě Azure Pipelines udělit přístup k jejich úložištím v části Oprávnění zde. Musíte být přidáni jako spolupracovník v nastavení úložiště v části Spolupracovníci. Přijměte pozvánku jako spolupracovníka pomocí odkazu, který vám pošle e-mail.

  • Pokud je úložiště v organizaci GitHubu, kterou vlastníte, alespoň jednou, pomocí OAuth ověřte gitHub pomocí svých osobních přihlašovacích údajů k účtu GitHub. To je možné provést v nastavení projektu Azure DevOps v části Připojení služby Pipelines > Service > Nové připojení služby > GitHub > Authorize. Udělte službě Azure Pipelines přístup k vaší organizaci v části Přístup k organizaci tady. Musíte být přidáni jako spolupracovník nebo musíte přidat váš tým v nastavení úložiště v části Spolupracovníci a týmy.

  • Pokud je úložiště v organizaci GitHubu, kterou vlastní někdo jiný, aspoň jednou, musí se vlastník organizace GitHubu ověřit na GitHubu pomocí OAuth pomocí svých osobních přihlašovacích údajů účtu GitHubu. To je možné provést v nastavení projektu Azure DevOps v části Připojení služby Pipelines > Service > Nové připojení služby > GitHub > Authorize. Vlastník organizace musí udělit službě Azure Pipelines přístup k organizaci v části Přístup organizace zde. Musíte být přidáni jako spolupracovník nebo musíte přidat váš tým v nastavení úložiště v části Spolupracovníci a týmy. Přijměte pozvánku jako spolupracovníka pomocí odkazu, který vám pošle e-mail.

Odvolání přístupu OAuth

Jakmile azure Pipelines autorizujete, aby používal OAuth, můžete ho později odvolat a zabránit dalšímu použití, navštivte OAuth Apps v nastavení GitHubu. Můžete ho také odstranit ze seznamu připojení služby GitHubu v nastavení projektu Azure DevOps.

Ověřování tokenu PAT (Personal Access Token)

pats jsou efektivně stejné jako OAuth, ale umožňují řídit, která oprávnění jsou udělena službě Azure Pipelines. Aktualizace stavu buildů a GitHubu se budou provádět jménem vaší osobní identity GitHubu. Aby buildy fungovaly dál, musí mít přístup k úložišti stále aktivní.

Pokud chcete vytvořit pat, navštivte osobní přístupové tokeny v nastavení GitHubu. Požadovaná oprávnění jsou repo, admin:repo_hook, read:usera user:email. Jedná se o stejná oprávnění požadovaná při použití OAuth výše. Zkopírujte vygenerovaný pat do schránky a vložte ho do nového připojení ke službě GitHub v nastavení projektu Azure DevOps. Pro budoucí odvolání pojmenujte připojení služby po uživatelském jménu GitHubu. Bude k dispozici v projektu Azure DevOps pro pozdější použití při vytváření kanálů.

Oprávnění potřebná v GitHubu

Pokud chcete vytvořit kanál pro úložiště GitHub s průběžnou integrací a triggery žádostí o přijetí změn, musíte mít nakonfigurovaná požadovaná oprávnění GitHubu. V opačném případě se úložiště při vytváření kanálu nezobrazí v seznamu úložišť. V závislosti na typu ověřování a vlastnictví úložiště se ujistěte, že je nakonfigurovaný následující přístup.

  • Pokud je úložiště ve vašem osobním účtu GitHubu, musí mít pat požadované obory přístupu v části Osobní přístupové tokeny: repo, admin:repo_hook, read:usera user:email.

  • Pokud je úložiště v osobním účtu GitHubu někoho jiného, musí mít pat požadované obory přístupu v rámci osobní přístupové tokeny: repo, admin:repo_hook, read:usera user:email. Musíte být přidáni jako spolupracovník v nastavení úložiště v části Spolupracovníci. Přijměte pozvánku jako spolupracovníka pomocí odkazu, který vám pošle e-mail.

  • Pokud je úložiště v organizaci GitHubu, kterou vlastníte, musí mít pat požadované obory přístupu v rámci osobní přístupové tokeny: repo, admin:repo_hook, read:usera user:email. Musíte být přidáni jako spolupracovník nebo musíte přidat váš tým v nastavení úložiště v části Spolupracovníci a týmy.

  • Pokud je úložiště v organizaci GitHubu, kterou vlastní někdo jiný, musí mít pat požadované obory přístupu v rámci osobní přístupové tokeny: repo, admin:repo_hook, read:usera user:email. Musíte být přidáni jako spolupracovník nebo musíte přidat váš tým v nastavení úložiště v části Spolupracovníci a týmy. Přijměte pozvánku jako spolupracovníka pomocí odkazu, který vám pošle e-mail.

Odvolání přístupu PAT

Po autorizaci služby Azure Pipelines pro použití pat ji později odstraňte a zabránili dalšímu použití, navštivte osobní přístupové tokeny v nastavení GitHubu. Můžete ho také odstranit ze seznamu připojení služby GitHubu v nastavení projektu Azure DevOps.

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
  • Classic

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

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 zástupných znaků.

Poznámka

Proměnné v triggerech nelze použít, 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, je nutné 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ěna odešle do main nebo do jakékoli větve vydané verze. Pokud se ale změní větev vydané verze, která začíná old, se neaktivuje.

Pokud zadáte klauzuli exclude bez klauzule include, je ekvivalentní zadání * v klauzuli include.

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

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

Pokud jste nezadali žádné triggery a Zakázat implicitní aktivační událost CI YAML není povolené, 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 batch na 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 se v triggerech prostředků úložiště nepodporuje.

Abychom tento příklad vysvětlili, řekněme, že nabízené A, které main způsobily spuštění výše uvedeného kanálu. V době, kdy je kanál spuštěný, se do úložiště objeví další nabízené B a C. 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í.

Stezky

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 vynechat branches k filtrování všech větví ve spojení s filtrem cesty.

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

  • 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 pak 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é v cestách nelze použít, protože proměnné se vyhodnocují za běhu (po aktivaci triggeru).

Visačky

Kromě zadávání značek v seznamech branches, 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

Triggery CI můžete úplně zrušit 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.

Přeskočení CI pro jednotlivá potvrzení

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 složky docs, 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é kóty

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í, aby * odpovídaly nule nebo více znaků a ? odpovídaly jednomu znaku.

  • Pokud začnete s * v kanálu YAML, musíte vzor zabalit do uvozovek, jako je "*-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. Je možné, že nebudete zahrnout * doprostřed filtru cesty a ?použít .
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 s jednou ze zadaných cílových větví nebo při aktualizaci takové žádosti o přijetí změn.

  • YAML
  • Classic

Větve

Cílové větve můžete zadat při ověřování žádostí o přijetí změn. Pokud chcete například ověřit žádosti o přijetí změn, které cílí na main a releases/*, můžete použít následující trigger pr.

pr:
- main
- releases/*

Tato konfigurace spustí nové spuštění při prvním vytvoření nové žádosti o přijetí změn a po každé aktualizaci provedené v žádosti o přijetí změn.

Můžete zadat úplný název větve (například main) nebo zástupný znak (například releases/*).

Poznámka

Proměnné v triggerech nelze použít, 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.

GitHub vytvoří novou ref při vytvoření žádosti o přijetí změn. Odkaz odkazuje na potvrzení sloučení, což je sloučený kód mezi zdrojovými a cílovými větvemi žádosti o přijetí změn. Kanál ověření žádosti o přijetí změn sestaví potvrzení, na které odkazuje tento odkaz. To znamená, že soubor YAML, který se používá ke spuštění kanálu, je také sloučením mezi zdrojem a cílovou větví. V důsledku toho můžou změny provedené v souboru YAML ve zdrojové větvi žádosti o přijetí změn přepsat chování definované souborem YAML v cílové větvi.

Pokud se v souboru YAML nezobrazí žádné pr triggery, ověřování žádostí o přijetí změn se automaticky povolí pro všechny větve, jako kdybyste napsali následující trigger pr. Tato konfigurace aktivuje sestavení při vytvoření jakékoli žádosti o přijetí změn a když potvrzení přicházejí do zdrojové větve jakékoli aktivní žádosti o přijetí změn.

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

Důležitý

Když zadáte aktivační událost pr s podmnožinou větví, kanál se aktivuje jenom v případě, že se do těchto větví nasdílí aktualizace.

Pro složitější triggery, které potřebují vyloučit určité větve, musíte použít úplnou syntaxi, jak je znázorněno v následujícím příkladu. V tomto příkladu se ověřují žádosti o přijetí změn, které cíl main nebo releases/* a releases/old* větve jsou vyloučené.

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

Stezky

Můžete zadat cesty k souborům, které chcete zahrnout nebo vyloučit. Například:

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

Tipy:

  • Azure Pipelines publikuje neutrální stav zpět na GitHub, když se rozhodne nespouštět ověřovací sestavení kvůli pravidlu vyloučení cesty. To poskytuje jasný směr na GitHub, který označuje, že Služba Azure Pipelines dokončila zpracování. Další informace najdete v tématu Post neutral status to GitHub při vynechání sestavení.
  • zástupné znaky jsou nyní podporovány filtry 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 pak 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é v cestách nelze použít, protože proměnné se vyhodnocují za běhu (po aktivaci triggeru).
  • Azure Pipelines publikuje neutrální stav zpět na GitHub, když se rozhodne nespouštět ověřovací sestavení kvůli pravidlu vyloučení cesty.

Několik aktualizací žádosti o přijetí změn

Můžete určit, jestli by se u stejné žádosti o přijetí změn měly zrušit probíhající ověřování. Výchozí hodnota je true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Ověření konceptu žádosti o přijetí změn

Ve výchozím nastavení se žádosti o přijetí změn aktivují u konceptů žádostí o přijetí změn a žádostí o přijetí změn, které jsou připravené ke kontrole. Pokud chcete zakázat triggery žádostí o přijetí změn pro koncepty žádostí o přijetí změn, nastavte vlastnost drafts na false.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Odhlášení od ověření žádosti o přijetí změn

Ověření žádosti o přijetí změn můžete zcela zrušit zadáním pr: none.

# no PR triggers
pr: none

Další informace najdete v tématu aktivační události žádosti o přijetí změn ve schématu YAML.

Poznámka

Pokud se trigger pr neaktivuje, postupujte podle kroků pro řešení potíží v nejčastějších dotazech.

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, které mají trigger žádosti o přijetí změn v cílové větvi žádosti o přijetí změn, se spustí na sloučení potvrzení (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é nasdílené 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, pokud zpráva nebo popis potvrzení sloučení neobsahuje [skip ci] (nebo žádné její varianty).

Chráněné větve

Ověřovací sestavení můžete spustit s jednotlivými potvrzeními nebo žádostmi o přijetí změn, které cílí na větev, a dokonce můžete zabránit sloučení žádostí o přijetí změn, dokud se sestavení ověření nepodaří.

Pokud chcete nakonfigurovat povinná ověření sestavení pro úložiště GitHub, musíte být jeho vlastníkem, spolupracovníkem s rolí Správce nebo členem organizace GitHubu s rolí Zapisovat.

  1. Nejprve vytvořte kanál pro úložiště a vytvořte ho alespoň jednou, aby se jeho stav publikoval do GitHubu, čímž GitHubu oznámí název kanálu.

  2. Dále postupujte podle dokumentace GitHubu k konfiguraci chráněných větví v nastavení úložiště.

    Pro kontrolu stavu vyberte název kanálu v seznamu Kontroly stavu.

    kontroly stavu kanálu GitHubu

Důležitý

Pokud se váš kanál nezobrazuje v tomto seznamu, ujistěte se, že platí následující:

  • Používáte ověřování aplikací GitHubu.
  • Kanál se spustil alespoň jednou za poslední týden.

Příspěvky z externích zdrojů

Pokud je vaše úložiště GitHubu opensourcové, můžete nastavit projekt Azure DevOps jako veřejný, aby každý mohl zobrazit výsledky sestavení, protokoly a výsledky testů vašeho kanálu bez přihlášení. Když uživatelé mimo vaši organizaci rozvětvují úložiště a odesílají žádosti o přijetí změn, můžou zobrazit stav buildů, které tyto žádosti o přijetí změn automaticky ověřují.

Při používání služby Azure Pipelines ve veřejném projektu při přijímání příspěvků z externích zdrojů byste měli mít na paměti následující aspekty.

Omezení přístupu

Při spouštění kanálů ve veřejných projektech Azure DevOps mějte na paměti následující omezení přístupu:

  • tajné kódy: Ve výchozím nastavení nejsou tajné kódy přidružené k vašemu kanálu k dispozici pro ověření forků žádostí o přijetí změn. Viz Ověření příspěvků z forků.
  • přístup mezi projekty: Všechny kanály ve veřejném projektu Azure DevOps se spouští s přístupovým tokenem omezeným na projekt. Kanály ve veřejném projektu mají přístup k prostředkům, jako jsou artefakty sestavení nebo výsledky testů, pouze v rámci projektu a ne v jiných projektech organizace Azure DevOps.
  • balíčky Azure Artifacts: Pokud vaše kanály potřebují přístup k balíčkům z Azure Artifacts, musíte explicitně udělit oprávnění účtu Project Build Service pro přístup k informačním kanálům balíčků.

Příspěvky z forků

Důležitý

Tato nastavení ovlivňují zabezpečení vašeho kanálu.

Když vytvoříte kanál, automaticky se aktivuje pro žádosti o přijetí změn z forků úložiště. Toto chování můžete změnit pečlivě s ohledem na to, jak ovlivňuje zabezpečení. Povolení nebo zakázání tohoto chování:

  1. Přejděte do projektu Azure DevOps. Vybertekanály , vyhledejte kanál a vyberte Upravit.
  2. Vyberte kartu Triggery. Po povolení triggeru žádosti o přijetí změn povolte nebo zakažte zaškrtávací políčko Sestavení žádostí o přijetí změn z forků tohoto úložiště.

Ve výchozím nastavení se u kanálů GitHubu nedostupují tajné kódy přidružené k vašemu kanálu buildu pro sestavení forků žádostí o přijetí změn. Tyto tajné kódy jsou ve výchozím nastavení povolené pomocí kanálů GitHub Enterprise Serveru. Mezi tajné kódy patří:

  • Token zabezpečení s přístupem k úložišti GitHub.
  • Tyto položky, pokud je váš kanál používá:

Pokud chcete obejít toto opatření v kanálech GitHubu, povolte políčko Zpřístupnit tajné kódy pro sestavení forků. Mějte na paměti, že toto nastavení má vliv na zabezpečení.

Poznámka

Když povolíte vytváření forků pro přístup k tajným kódům, Azure Pipelines ve výchozím nastavení omezí přístupový token používaný pro sestavení forku. Má omezenější přístup k otevřeným prostředkům než normální přístupový token. Pokud chcete vytvořit fork stejná oprávnění jako běžná sestavení, povolte sestavení forku Vytvořit fork stejná oprávnění jako běžná sestavení nastavení.

Další informace najdete v tématu Ochrana úložiště – Forky.

Centrálně můžete definovat, jak kanály vytvářejí žádosti o přijetí změn z rozvětvovaných úložišť GitHubu pomocí Omezit vytváření žádostí o přijetí změn z forků úložišť GitHub řízení. Je k dispozici na úrovni organizace a projektu. Můžete zvolit:

  • Zakázání vytváření žádostí o přijetí změn z forkovaných úložišť
  • Bezpečné sestavování žádostí o přijetí změn z forkovaných úložišť
  • Přizpůsobení pravidel pro vytváření žádostí o přijetí změn z forkovaných úložišť

Snímek obrazovky s centralizovaným nastavením řízení, jak kanály vytvářejí žádosti o přijetí změn z forků úložišť GitHubu

Počínaje Sprint 229, aby se zlepšilo zabezpečení vašich kanálů, Azure Pipelines už nevytvářejí žádosti o přijetí změn z forkovaných úložišť GitHubu. U nových projektů a organizací je výchozí hodnota Omezit vytváření žádostí o přijetí změn z rozvětvovaných úložišť GitHubu nastavení Zakázat vytváření žádostí o přijetí změn z forkovaných úložišť.

Když zvolíte možnost Bezpečné sestavení žádostí o přijetí změn z rozvětvovaných úložišť možnost, nebudou všechny kanály, organizace nebo projektové, zpřístupnit tajné kódy pro sestavení žádostí o přijetí změn z forkovaných úložišť, nemůže vytvářet tato sestavení stejná oprávnění jako normální sestavení a musí aktivovat komentář k žádosti o přijetí změn. Projekty se stále můžou rozhodnout, že nebudou umožnit kanálům vytvářet takové žádosti o přijetí změn.

Když zvolíte možnost Přizpůsobit, můžete definovat, jak omezit nastavení kanálu. Můžete například zajistit, aby všechny kanály vyžadovaly komentář, aby bylo možné vytvořit žádost o přijetí změn z rozvětvovaného úložiště GitHubu, když žádost o přijetí změn patří členům, kteří nejsou členy týmu a nesdílejí. Můžete se ale rozhodnout, že jim povolíte zpřístupnění tajných kódů pro tyto buildy. Projekty se můžou rozhodnout, že nebudou umožnit kanálům vytvářet takové žádosti o přijetí změn nebo je bezpečně vytvářet nebo mít ještě více omezující nastavení, než je uvedeno na úrovni organizace.

Ovládací prvek je vypnutý pro stávající organizace. od září 2023 mají nové organizace bezpečně vytvářet žádosti o přijetí změn z forkovaných úložišť ve výchozím nastavení zapnuté.

Důležité aspekty zabezpečení

Uživatel GitHubu může vytvořit fork úložiště, změnit ho a vytvořit žádost o přijetí změn, která navrhne změny v úložišti. Tato žádost o přijetí změn může obsahovat škodlivý kód, který se má spustit jako součást aktivovaného sestavení. Takový kód může způsobit poškození následujícími způsoby:

  • Únik tajných kódů z kanálu Pokud chcete toto riziko zmírnit, nepovolujte Zpřístupnit tajné kódy pro sestavení forků zaškrtávací políčko, pokud je vaše úložiště veřejné nebo nedůvěryhodné uživatele můžou odesílat žádosti o přijetí změn, které automaticky aktivují sestavení. Tato možnost je ve výchozím nastavení zakázaná.

  • Narušte počítač, na kterém běží agent, aby ukradl kód nebo tajné kódy z jiných kanálů. Pokud chcete tento problém zmírnit:

    • K vytváření žádostí o přijetí změn z forků použijte fond agentů hostovaný Microsoftem. Počítače agenta hostované Microsoftem se okamžitě odstraní po dokončení sestavení, takže pokud dojde k ohrožení zabezpečení, nebude to mít žádný trvalý dopad.

    • Pokud musíte použít agenta v místním prostředí, neukládejte žádné tajné kódy ani neprovádějte jiné buildy a vydané verze, které používají tajné kódy na stejném agentovi, pokud vaše úložiště není soukromé a důvěřujete tvůrcům žádostí o přijetí změn.

Triggery komentářů

Spolupracovníci úložiště můžou komentovat žádost o přijetí změn a ručně spustit kanál. Tady je několik běžných důvodů, proč byste to mohli chtít udělat:

  • Je možné, že nebudete chtít automaticky vytvářet žádosti o přijetí změn od neznámých uživatelů, dokud nebude možné jejich změny zkontrolovat. Chcete, aby jeden z členů týmu nejprve zkontroloval svůj kód a pak spustil kanál. To se běžně používá jako bezpečnostní opatření při sestavování kódu přispívání z forkovaných úložišť.
  • Můžete chtít spustit volitelnou testovací sadu nebo jeden více sestavení ověření.

Pokud chcete povolit triggery komentářů, musíte postupovat následovně:

  1. Povolte triggery žádostí o přijetí změn pro váš kanál a ujistěte se, že jste cílovou větev nevyloučili.
  2. Na webovém portálu Azure Pipelines upravte kanál a zvolte Další akce, Triggery. Potom v části ověření žádosti o přijetí změnpovolte Vyžadovat komentář člena týmu před vytvořením žádosti o přijetí změn.
    • Před vytvořením žádosti o přijetí změn zvolte U všech žádostí o přijetí změn vyžadovat komentář člena týmu. V tomto pracovním postupu člen týmu zkontroluje žádost o přijetí změn a aktivuje sestavení s komentářem, jakmile se žádost o přijetí změn považuje za bezpečnou.
    • Zvolte Pouze u žádostí o přijetí změn od členů, kteří nejsou členy týmu, požadovat komentář člena týmu pouze v případech, kdy žádost o přijetí změn provede jiný člen týmu. V tomto pracovním postupu člen týmu k aktivaci sestavení nepotřebuje kontrolu sekundárního člena týmu.

S těmito dvěma změnami se sestavení ověření žádosti o přijetí změn neaktivuje automaticky, pokud Pouze u žádostí o přijetí změn od členů, kteří nejsou členy týmu, a žádost o přijetí změn provede člen týmu. Sestavení můžou aktivovat jenom vlastníci úložiště a spolupracovníci s oprávněním Zapisovat, a to tak, že zakomentují žádost o přijetí změn pomocí /AzurePipelines run nebo /AzurePipelines run <pipeline-name>.

V komentářích můžete službě Azure Pipelines vydat následující příkazy:

Příkaz Výsledek
/AzurePipelines help Zobrazení nápovědy pro všechny podporované příkazy
/AzurePipelines help <command-name> Zobrazí nápovědu pro zadaný příkaz.
/AzurePipelines run Spusťte všechny kanály, které jsou přidružené k tomuto úložišti a jejichž triggery tuto žádost o přijetí změn nevyloučí.
/AzurePipelines run <pipeline-name> Spusťte zadaný kanál, pokud jeho triggery tuto žádost o přijetí změn nevyloučí.

Poznámka

Pro stručnost můžete komentář použít /azp místo /AzurePipelines.

Důležitý

Odpovědi na tyto příkazy se zobrazí v diskuzi o žádosti o přijetí změn pouze v případě, že váš kanál používá aplikace Azure Pipelines na GitHubu.

Řešení potíží s triggery komentářů žádostí o přijetí změn

Pokud máte potřebná oprávnění k úložišti, ale kanály se neaktivují vašimi komentáři, ujistěte se, že vaše členství je veřejné v organizaci úložiště, nebo se přímo přidejte jako spolupracovník úložiště. Kanály nevidí soukromé členy organizace, pokud nejsou přímými spolupracovníky nebo nepatří do týmu, který je přímým spolupracovníkem. Členství v organizaci GitHubu můžete změnit ze soukromého na veřejné (nahraďte Your-Organization názvem vaší organizace): https://github.com/orgs/Your-Organization/people.

Informační běhy

Informační spuštění sděluje, že se službě Azure DevOps nepodařilo načíst zdrojový kód kanálu YAML. Načítání zdrojového kódu probíhá v reakci na externí události, například nabízené potvrzení. Dochází také v reakci na interní triggery, například kvůli kontrole, jestli nedošlo ke změnám kódu, a spuštění naplánovaného spuštění nebo ne. Načítání zdrojového kódu může selhat z několika důvodů, přičemž často dochází k omezování požadavků poskytovatelem úložiště Git. Existence informačního spuštění nemusí nutně znamenat, že azure DevOps bude kanál spouštět.

Informační spuštění vypadá jako na následujícím snímku obrazovky.

snímek obrazovky se spuštěním informačního kanálu

Informační spuštění můžete rozpoznat pomocí následujících atributů:

  • Stav je Canceled
  • Doba trvání je < 1s
  • Název spuštění obsahuje jeden z následujících textů:
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • Název spuštění obecně obsahuje chybu BitBucket nebo GitHub, která způsobila selhání načtení kanálu YAML.
  • Žádné fáze / úlohy / kroky

Další informace o informačních spuštěních.

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 pomocí 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 System.PreferGitFromPath na true. Toto nastavení platí vždy u agentů jiných než Windows.

Cesta k pokladně

  • YAML
  • Classic

Pokud si ve výchozím nastavení rezervujete jedno úložiště, váš zdrojový kód bude rezervován do adresáře s názvem s. U kanálů YAML to můžete změnit zadáním checkout pomocí path. Zadaná cesta je relativní k $(Agent.BuildDirectory). Například: Pokud je hodnota cesty rezervace mycustompath a $(Agent.BuildDirectory) je 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 rezervaci 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 například rezervovat dvě úložiště s názvem tools a code, zdrojový kód bude rezervován do C:\agent\_work\1\s\tools a C:\agent\_work\1\s\code.

Upozorňujeme, že hodnotu cesty rezervace nelze nastavit tak, aby se nad $(Agent.BuildDirectory)zobrazily žádné úrovně adresáře, takže path\..\anotherpath způsobí platnou cestu k pokladně (tj. C:\agent\_work\1\anotherpath), ale hodnota, jako je ..\invalidpath, nebude (tj. C:\agent\_work\invalidpath).

Nastavení path můžete nakonfigurovat 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

Submoduly

  • YAML
  • Classic

Nastavení submodules můžete nakonfigurovat 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

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

  • Neověřené: veřejného neověřeného ú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

      • Tato aplikace by byla rezervována: 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.

      • 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čích modulů 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čích modulů rezervace, můžete místo toho k načtení dílčích modulů použít vlastní skript. Nejprve získejte token PAT (Personal Access Token) a předponu ho předponou pat:. Dále kódování base64 tento řetězec s předponou k vytvoření základního ověřovacího tokenu. 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 na vašem privátním agentu 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á při načítání obsahu úložiště Git možnost --tags. 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 chcete synchronizovat značky při rezervaci úložiště, můžete v YAML nakonfigurovat nastavením vlastnosti fetchTags a v uživatelském rozhraní konfigurací nastavení Synchronizovat značky.

  • YAML
  • Classic

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

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

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.

    Snímek obrazovky s nabídkou dalších triggerů

  2. Zvolte YAML , Získat zdroje.

    snímek obrazovky se získáním zdrojů

  3. Nakonfigurujte nastavení značky synchronizace .

    Snímek obrazovky s nastavením Synchronizovat značky

Poznámka

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

Výchozí chování

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

Poznámka

Pokud explicitně nastavíte fetchTags v kroku checkout, toto nastavení má 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 efektivně git fetch --depth=n. 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 ze září 2022 Pro Sprint 209 pro Azure DevOps 209 mají mělké načtení ve výchozím nastavení povolené a nakonfigurované s hloubkou 1. Dříve se výchozí hodnota nenačítá. Pokud chcete zkontrolovat kanál, podívejte se na nastavení Mělké načtení v uživatelském rozhraní nastavení kanálu, jak je popsáno v následující části.

  • YAML
  • Classic

Nastavení fetchDepth můžete nakonfigurovat 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 nakonfigurovat také nastavením možnosti Mělké hloubky v uživatelském rozhraní nastavení kanálu.

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

    Snímek obrazovky s nabídkou dalších triggerů

  2. Zvolte YAML , Získat zdroje.

    snímek obrazovky se získáním zdrojů

  3. Nakonfigurujte nastavení Mělké načtení. Zrušte zaškrtnutí Mělké načtení, 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í.

    Snímek obrazovky s možnostmi

Poznámka

Pokud explicitně nastavíte fetchDepth v kroku checkout, toto nastavení má 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í Mělké načtení.

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
  • Classic

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

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

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 úlohy nebo nástroje, 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
  • Classic

Nastavení clean můžete nakonfigurovat 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

Pokud je clean nastavena na true kanál buildu provede vrácení změn 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 můžete nakonfigurovat 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 plus: Odstraní a znovu vytvoří $(Build.BinariesDirectory). Mějte na paměti, že $(Build.ArtifactStagingDirectory) a $(Common.TestResultsDirectory) se vždy odstraní a znovu vytvoří před každým sestavením bez ohledu na toto nastavení.

  • prostředky: 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: 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
  • Classic

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

Konfigurace možností Gitu, YAML.

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

Z klasického editoru zvolte YAML > Získat zdroje.

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 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é, jako jsou $(Build.RequestedFor) a $(Build.DefinitionName), můžou 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 Git refs/tags/{tag}. 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é.

Předdefinované proměnné

Když sestavíte úložiště GitHub, většina předdefinovaných proměnných jsou pro vaše úlohy k dispozici. Vzhledem k tomu, že Azure Pipelines nerozpozná identitu uživatele, který provádí aktualizaci na GitHubu, jsou následující proměnné nastavené na systémovou identitu místo identity uživatele:

  • Build.RequestedFor
  • Build.RequestedForId
  • Build.RequestedForEmail

Aktualizace stavu

Existují dva typy stavů, které Azure Pipelines publikuje zpět na GitHub – základní stavy a spuštění kontroly GitHubu. Funkce GitHub Checks je dostupná jenom u aplikací GitHubu.

Stavy kanálů se zobrazují na různých místech v uživatelském rozhraní GitHubu.

  • V případě žádostí o přijetí změn se zobrazí na kartě Konverzace k žádosti o přijetí změn.
  • U jednotlivých potvrzení se zobrazí při najetí myší na stavovou značku po době potvrzení na kartě potvrzení úložiště.

Připojení PAT nebo OAuth na GitHubu

U kanálů používajících PAT nebo připojení OAuth GitHubu se stavy publikují zpět do potvrzení nebo žádosti o přijetí změn, které aktivovaly spuštění. K publikování těchto aktualizací se používá rozhraní API stavu GitHubu. Tyto stavy obsahují omezené informace: stav kanálu (selhání, úspěch), adresu URL pro odkaz zpět na kanál buildu a stručný popis stavu.

Stavy připojení PAT nebo OAuth Na GitHubu se odesílají jenom na úrovni spuštění. Jinými slovy, můžete mít jeden stav aktualizovaný pro celé spuštění. Pokud máte ve spuštění více úloh, nemůžete pro každou úlohu publikovat samostatný stav. Několik kanálů však může publikovat samostatné stavy do stejného potvrzení.

Kontroly GitHubu

U kanálů nastavených pomocí aplikace Azure Pipelines GitHubu se stav publikuje zpět ve formě GitHub Checks. Kontroly GitHubu umožňují odesílat podrobné informace o stavu a testování kanálu, pokrytí kódu a chybách. Rozhraní API GitHub Checks najdete zde.

Pro každý kanál, který používá aplikaci GitHub, se kontroly publikují zpět pro celkové spuštění a každou úlohu v daném spuštění.

GitHub umožňuje tři možnosti v případě selhání jedné nebo několika neúspěšných spuštění kontroly žádosti o přijetí změn nebo potvrzení. Můžete se rozhodnout znovu spustit jednotlivou kontrolu, znovu spustit všechny neúspěšné kontroly v žádosti o přijetí změn nebo potvrzení, nebo znovu spustit všechny kontroly, ať už byly původně úspěšné nebo ne.

kontroly GitHubu znovu spustit

Po kliknutí na odkaz Znovu spustit vedle názvu Zkontrolovat spuštění se v Azure Pipelines znovu pokusí spustit, které vygenerovalo spuštění kontroly. Výsledné spuštění bude mít stejné číslo spuštění a použije stejnou verzi zdrojového kódu, konfigurace a souboru YAML jako počáteční sestavení. Znovu se spustí pouze úlohy, které selhaly při počátečním spuštění a všechny závislé podřízené úlohy. Kliknutím na odkaz Znovu spustit všechny neúspěšné kontroly se projeví stejný účinek. Jedná se o stejné chování jako při kliknutí na Opakovat spuštění v uživatelském rozhraní Azure Pipelines. Kliknutím na "Znovu spustit všechny kontroly" se spustí nové spuštění s novým číslem spuštění a vyzvedne změny v konfiguračním souboru nebo souboru YAML.

Omezení

  • Pro dosažení nejlepšího výkonu doporučujeme v jednom úložišti maximálně 50 kanálů. Pro přijatelný výkon doporučujeme maximálně 100 kanálů v jednom úložišti. Doba potřebná ke zpracování nasdílení změn do úložiště se zvyšuje s počtem kanálů v daném úložišti. Kdykoli se do úložiště nasdílí oznámení, Azure Pipelines musí načíst všechny kanály YAML v daném úložišti, aby zjistili, jestli některý z nich musí běžet, a načtení každého kanálu způsobuje snížení výkonu. Kromě problémů s výkonem může příliš mnoho kanálů v jednom úložišti vést k omezování na straně GitHubu, protože Azure Pipelines může za krátkou dobu provádět příliš mnoho požadavků.

  • Použití rozšiřuje a zahrnuje šablony v kanálu ovlivňuje rychlost, s jakou Azure Pipelines vytváří požadavky rozhraní API GitHubu a může vést k omezování na straně GitHubu. Před spuštěním kanálu musí Azure Pipelines vygenerovat kompletní kód YAML, takže musí načíst všechny soubory šablon.

  • Azure Pipelines načte z úložiště maximálně 2000 větví do rozevíracích seznamů na portálu Azure DevOps, například v okně Vyberte větev pro Výchozí větev pro ruční a plánované sestavení nastavení nebo při ručním výběru větve při spuštění kanálu.

    Pokud požadovanou větev v seznamu nevidíte, zadejte požadovaný název větve ručně do pole Výchozí větev pro ruční a naplánované sestavení.

    Pokud kliknete na tři tečky a otevřete dialogové okno Vybrat větev a zavřete ji bez výběru platné větve z rozevíracího seznamu, může se zobrazit Některá nastavení vyžadují pozornost zprávy a Toto nastavení je nutné zpráva níže Výchozí větev pro ruční a naplánované buildy. Pokud chcete tuto zprávu obejít, znovu otevřete kanál a zadejte název přímo do výchozí větve pro ruční a naplánované sestavení pole.

FAQ

Problémy související s integrací GitHubu spadají do následujících kategorií:

Typy připojení

Jak zjistím typ připojení GitHubu, který používám pro svůj kanál, jak řešit potíže s triggery?

Řešení potíží s triggery velmi závisí na typu připojení GitHubu, které používáte ve svém kanálu. Existují dva způsoby, jak určit typ připojení – z GitHubu a z Azure Pipelines.

  • Z GitHubu: Pokud je úložiště nastavené tak, aby používalo aplikaci GitHub, budou se stavy žádostí o přijetí změn a potvrzení kontrolovat spuštění. Pokud má úložiště nastavené azure Pipelines s připojeními OAuth nebo PAT, budou se stavy ve stavu "starých". Rychlý způsob, jak zjistit, jestli jsou stavy Kontrola spuštění nebo jednoduché stavy, je podívat se na kartu "konverzace" na žádosti o přijetí změn GitHubu.

    • Pokud se odkaz Podrobnosti přesměruje na kartu Kontroly, jedná se o spuštění kontroly a úložiště používá aplikaci.
    • Pokud se odkaz Podrobnosti přesměruje do kanálu Azure DevOps, stav je "starý styl" a úložiště nepoužívá aplikaci.

  • Z Azure Pipelines: Typ připojení můžete také určit kontrolou kanálu v uživatelském rozhraní Azure Pipelines. Otevřete editor kanálu. Výběrem Triggery otevřete klasický editor kanálu. Potom vyberte YAML a pak krok Získat zdroje. Všimnete si banneru Autorizované pomocí připojení: označující připojení služby, které se použilo k integraci kanálu s GitHubem. Název připojení služby je hypertextový odkaz. Vyberte ho a přejděte do vlastností připojení služby. Vlastnosti připojení služby budou znamenat typ používaného připojení:

    • aplikace Azure Pipelines označuje připojení aplikace GitHub
    • oauth označuje připojení OAuth
    • personalaccesstoken označuje ověřování PAT.

Jak můžu přepnout kanál tak, aby místo OAuth používal aplikaci GitHub?

Použití aplikace GitHub místo připojení OAuth nebo PAT je doporučenou integrací mezi GitHubem a Azure Pipelines. Pokud chcete přepnout na aplikaci GitHub, postupujte takto:

  1. Přejděte sem a nainstalujte aplikaci v organizaci úložiště GitHub.
  2. Během instalace budete přesměrováni na Azure DevOps a zvolit organizaci a projekt Azure DevOps. Zvolte organizaci a projekt, který obsahuje klasický kanál buildu, pro který chcete aplikaci použít. Tato volba přidruží instalaci aplikace GitHub k vaší organizaci Azure DevOps. Pokud se rozhodnete nesprávně, můžete navštívit této stránce odinstalovat aplikaci GitHub z vaší organizace GitHubu a začít znovu.
  3. Na další stránce, která se zobrazí, nemusíte pokračovat vytvořením nového kanálu.
  4. Kanál můžete upravit tak, že přejdete na stránku Pipelines (např. https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), vyberete kanál a kliknete na Upravit.
  5. Pokud se jedná o kanál YAML, výběrem nabídky Triggery otevřete klasický editor.
  6. V kanálu vyberte krok Získat zdroje.
  7. Na zeleném panelu s textem Autorizované pomocí připojení vyberte Změnit a vyberte připojení aplikace GitHub se stejným názvem jako organizace GitHubu, do které jste aplikaci nainstalovali.
  8. Na panelu nástrojů vyberte Uložit a frontu a pak Uložit a frontu. Vyberte odkaz na spuštění kanálu, které bylo zařazeno do fronty, a ujistěte se, že je úspěšné.
  9. Vytvořte v úložišti GitHubu žádost o přijetí změn (nebo ji zavřete a znovu otevřete) a ověřte, že se sestavení úspěšně zařadí do fronty v jeho části Kontroly.

Proč se mi v Azure Pipelines nezobrazuje úložiště GitHub?

V závislosti na typu ověřování a vlastnictví úložiště se vyžadují konkrétní oprávnění.

  • Pokud používáte aplikaci GitHub, přečtěte si ověřování aplikací GitHubu.
  • Pokud používáte OAuth, přečtěte si ověřování OAuth.
  • Pokud používáte paty, přečtěte siověřování pat ( Personal Access Token).

Když během vytváření kanálu vyberu úložiště, zobrazí se chyba Úložiště {název úložiště} se používá s aplikací Azure Pipelines Na GitHubu v jiné organizaci Azure DevOps.

To znamená, že vaše úložiště je už přidružené k kanálu v jiné organizaci. Události CI a PR z tohoto úložiště nebudou fungovat, protože se doručí do jiné organizace. Tady jsou kroky, které byste měli udělat, abyste před vytvořením kanálu odebrali mapování na jinou organizaci.

  1. Otevřete žádost o přijetí změn v úložišti GitHub a nastavte komentář /azp where. Tato sestava vrací organizaci Azure DevOps, na kterou je úložiště namapované.

  2. Pokud chcete mapování změnit, odinstalujte aplikaci z organizace GitHubu a znovu ji nainstalujte. Při přeinstalaci nezapomeňte při přesměrování na Azure DevOps vybrat správnou organizaci.

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ě:

  • Jsou triggery CI nebo PR YAML přepsány nastavením kanálu vuživatelského rozhraní? Při úpravě kanálu zvolte ... a pak Triggery.

    uživatelské rozhraní nastavení kanálu.

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

    přepsat trigger YAML odsud.

  • Používáte připojení aplikace GitHub k připojení kanálu k GitHubu? Pokud chcete určit typ připojení, který máte, přečtěte si typy připojení. Pokud používáte připojení aplikace GitHub, postupujte takto:

    • Je mapování správně nastavené mezi GitHubem a Azure DevOps? Otevřete žádost o přijetí změn v úložišti GitHub a nastavte komentář /azp where. Tato sestava vrací organizaci Azure DevOps, na kterou je úložiště namapované.

      • Pokud pro sestavení tohoto úložiště pomocí aplikace nejsou nastavené žádné organizace, přejděte na https://github.com/<org_name>/<repo_name>/settings/installations a dokončete konfiguraci aplikace.

      • Pokud je hlášena jiná organizace Azure DevOps, někdo už vytvořil kanál pro toto úložiště v jiné organizaci. V současné době máme omezení, které můžeme mapovat pouze na úložiště GitHubu na jednu organizaci DevOps. Automaticky se aktivují jenom kanály v první organizaci Azure DevOps. Pokud chcete mapování změnit, odinstalujte aplikaci z organizace GitHubu a znovu ji nainstalujte. Při přeinstalaci nezapomeňte při přesměrování na Azure DevOps vybrat správnou organizaci.

  • K připojení kanálu k GitHubu používáte OAuth nebo PAT? Pokud chcete určit typ připojení, který máte, přečtěte si typy připojení. Pokud používáte připojení GitHubu, postupujte takto:

    1. Připojení OAuth a PAT využívají webhooky ke komunikaci aktualizací do Azure Pipelines. Na GitHubu přejděte do nastavení úložiště a pak do Webhooků. Ověřte, že webhooky existují. Obvykle byste měli vidět tři webhooky – push, pull_request a issue_comment. Pokud ne, musíte znovu vytvořit připojení služby a aktualizovat kanál tak, aby používal nové připojení služby.

    2. Vyberte všechny webhooky na GitHubu a ověřte, že datová část odpovídající potvrzení uživatele existuje a byla úspěšně odeslána do Azure DevOps. Pokud událost nemohla být komunikována do Azure DevOps, může se zde zobrazit chyba.

  • Provoz z Azure DevOps může GitHub omezovat. Když Azure Pipelines obdrží oznámení z GitHubu, pokusí se kontaktovat GitHub a načíst další informace o úložišti a souboru YAML. Pokud máte úložiště s velkým počtem aktualizací a žádostí o přijetí změn, může toto volání selhat kvůli takovému omezování. V tomto případě zjistěte, jestli můžete snížit frekvenci sestavení pomocí dávkových nebo přísnějších filtrů cesty nebo větví.

  • Je kanál pozastavený nebo zakázaný? Otevřete editor kanálu a pak vyberte Nastavení a zkontrolujte ho. 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 a pak postupujte následovně:

  • 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? Zpoždění můžete obvykle 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. Tady je několik důvodů, proč může docházet ke zpoždění:

    • Dochází k výpadku služby na naší stránce stavu . 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.
    • Vaše úložiště obsahuje příliš mnoho kanálů YAML. Pro dosažení nejlepšího výkonu doporučujeme v jednom úložišti maximálně 50 kanálů. Pro přijatelný výkon doporučujeme maximálně 100 kanálů v jednom úložišti. Čím více kanálů existuje, tím pomalejší je zpracování nabízeného oznámení do tohoto úložiště. Kdykoli se do úložiště nasdílí oznámení, azure Pipelines musí načíst všechny kanály YAML v daném úložišti, aby zjistily, jestli některý z nich musí běžet, a každý nový kanál má za následek snížení výkonu.

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

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 triggerů .
  3. Vyberte Přepsat trigger kontinuální integrace YAML odsud.
  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.

Neúspěšná rezervace

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

remote: Repository not found.
fatal: repository <repo> not found

Příčinou může být výpadek GitHubu. Zkuste získat přístup k úložišti na GitHubu a ujistěte se, že jste schopni.

Nesprávná verze

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

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

Chybějící aktualizace stavu

Moje žádost o přijetí změn na GitHubu je blokovaná, protože Služba Azure Pipelines neaktualizuje stav.

Může se jednat o přechodnou chybu, která způsobila, že Azure DevOps nemůže komunikovat s GitHubem. Pokud používáte aplikaci GitHub, zkuste se vrátit se změnami na GitHubu. Nebo proveďte triviální aktualizaci žádosti o přijetí změn, abyste zjistili, jestli se dá problém vyřešit.