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

  • Článek

Služby Azure DevOps

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 tématu 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 dokumentace k GitHubu.

GitHub organization structure

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

Azure DevOps organization structure

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

  • Organizace DevOps pro vaši organizaci Nebo uživatelský účet GitHubu
  • DevOps Projects pro vaše úložiště GitHub

GitHub structure mapped to 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. Příklad:

Service Adresa URL
GitHubu 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 se nacházejí na adrese https://github.com/orgs/your-organization/people (replace your-organization).

Oprávnění členů organizace DevOps najdete na adrese https://dev.azure.com/your-organization/_settings/security (nahradit 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 programu 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 oprávněními, která potřebujete.

Role uživatelského účtu GitHubu

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

Oprávnění členů organizace DevOps najdete na adrese https://dev.azure.com/your-organization/_settings/security (nahradit 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 na https://github.com/your-organization/your-repository/settings/collaboration adrese (replace your-organization a your-repository).

Oprávnění projektu DevOps najdete na https://dev.azure.com/your-organization/your-project/_settings/security adrese (nahradit 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
Správa Člen Project Administrators
Zapsat Člen Contributors
Přečí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 Teams části 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 Pipelines (například https://dev.azure.com/your-organization/your-project/_build) projektu.
  2. Vyberte kanál, pro který chcete nastavit konkrétní oprávnění.
  3. V místní nabídce ...vyberte Zabezpečení.
  4. Výběrem možnosti Přidat... přidáte konkrétního uživatele, týmu nebo skupiny a přizpůsobíte svá oprávnění pro kanál.

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

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ě s více úložišti.

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.

Authentication type Kanály se spouštějí pomocí Práce s GitHub Checks
1. Aplikace GitHubu Identita Azure Pipelines Ano
2. OAuth Vaše osobní identita GitHubu No
3. Pat přístupový token (PAT) Vaše osobní identita GitHubu No

Ověřování aplikací GitHubu

Aplikace Azure Pipelines na GitHubu je doporučeným typem 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 se službami GitHub Checks a zobrazuje výsledky 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. Jako alternativu k instalaci aplikace pro všechna úložiště ho můžou správci úložiště nainstalovat jednotlivě pro jednotlivá úložiště. To vyžaduje více práce pro správce, ale nemá žádnou výhodu ani nevýhodu.

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

Oprávnění 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 s úložišti 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 při vytváření kanálu jiné připojení pod seznamem úložišť. Pak vyberte Autorizovat pro přihlášení k GitHubu a autorizaci 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. Jinak 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í > ke službě GitHub > Authorize.> Udělte službě Azure Pipelines přístup k vašim úložištím v části Oprávnění.

  • 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í > ke službě GitHub > Authorize.> Druhý uživatel musí službě Azure Pipelines udělit přístup ke svým úložištím v části Oprávnění. 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í > ke službě GitHub > Authorize.> V části Přístup organizace udělte službě Azure Pipelines přístup k vaší 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.

  • 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í > ke službě GitHub > Authorize.> Vlastník organizace musí této organizaci udělit přístup ke službě Azure Pipelines v části Přístup organizace. 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

Po autorizaci služby Azure Pipelines pro použití OAuth ji můžete později odvolat a zabránit dalšímu použití, navštivte aplikace OAuth v nastavení GitHubu. Můžete ho také odstranit ze seznamu připojení služby GitHub v nastavení projektu Azure DevOps.

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

PaTs jsou v podstatě stejné jako OAuth, ale umožňují řídit, která oprávnění se udělují 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, přejděte do osobních přístupových tokenů 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í služby 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. Jinak 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 rámci osobních přístupových tokenů: 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ích přístupových tokenů: 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ích přístupových tokenů: 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ích přístupových tokenů: 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 odstraníte a zabráníte dalšímu použití, navštivte osobní přístupové tokeny v nastavení GitHubu. Můžete ho také odstranit ze seznamu připojení služby GitHub 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.

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

Větve

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

trigger:
- main
- releases/*

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

Poznámka:

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

Poznámka:

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

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

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

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

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

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

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

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

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

Důležité

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

Dávkové spuštění CI

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

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

Poznámka:

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

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

Poznámka:

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

Cesty

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

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

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

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

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

Značky

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

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

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

Důležité

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

Odhlášení z CI

Zakázání triggeru CI

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

# A pipeline with no CI trigger
trigger: none

Důležité

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

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 docs složky, a druhý kanál, který se aktivuje při nasdílení aktualizace kódu aplikace. V těchto případech je potřeba pochopit, jak se kanály aktivují při vytvoření nové větve.

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

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

Zástupné znaky

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

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

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

Triggery žádosti o přijetí změn způsobují spuštění kanálu při každém otevření žádosti o přijetí změn s jednou ze zadaných cílových větví nebo při aktualizaci takové žádosti o přijetí změn.

Větve

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

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

Poznámka:

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

GitHub při vytvoření žádosti o přijetí změn vytvoří nový odkaz . 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 aktivační události, ověřování žádostí o přijetí změn se automaticky povolí pro všechny větve, jako byste napsali následující pr trigger. 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 pr trigger s podmnožinou větví, kanál se aktivuje jenom v případě, že se aktualizace nasdílí do těchto větví.

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 žádosti o přijetí změn ověřují, že cíl main nebo releases/* větev releases/old* je vyloučená.

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

Cesty

Můžete zadat cesty k souborům, které chcete zahrnout nebo vyloučit. Pří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 when a build is skipped.
  • Zástupné znaky jsou teď podporovány s 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 , můžete zahrnout /tools/trigger-runs-on-these
  • Pořadífiltrůch
  • Cesty v Gitu rozlišují malá a velká písmena. Nezapomeňte použít stejný případ jako skutečné složky.
  • Proměnné nemůžete použít v cestách, protože proměnné se vyhodnocují za běhu (po aktivaci triggeru).
  • 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 drafts vlastnost na falsehodnotu .

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: nonepříkazu .

# no PR triggers
pr: none

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

Poznámka:

pr Pokud se trigger 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í aktivační událost žádosti o přijetí změn v cílové větvi žádosti o přijetí změn, se spustí při potvrzení sloučení (sloučený kód mezi zdrojovými a cílovými větvemi žádosti o přijetí změn), bez ohledu na to, jestli existují nabízená potvrzení, jejichž zprávy nebo popisy obsahují [skip ci] (nebo některé z jejích variant).
  • Kanály aktivované změnami zdrojové větve žádosti o přijetí změn, pokud neexistují žádná nabízená potvrzení, jejichž zprávy nebo popisy obsahují [skip ci] (nebo některé z jejích variant). Pokud alespoň jedno nabízené potvrzení obsahuje [skip ci], kanály se nespustí.

Nakonec po sloučení žádosti o přijetí změn spustí Azure Pipelines kanály CI aktivované odesláním do cílové větve, pokud zpráva nebo popis potvrzení sloučení neobsahuje [skip ci] (nebo žádnou z jejích variant).

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áva nebo členem organizace GitHubu s rolí Zápis.

  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 ke konfiguraci chráněných větví v nastavení úložiště.

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

    GitHub pipeline status check

Důležité

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

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

Pokud je vaše úložiště GitHubu opensourcové, můžete projekt Azure DevOps nastavit 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 zpřístupněné pro ověřování 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 běží 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í k účtu služby Sestavení projektu 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. Vyberte Kanály, vyhledejte kanál a vyberte Upravit.
  2. Vyberte kartu Aktivační události. Po povolení triggeru žádosti o přijetí změn povolte nebo zakažte zaškrtávací políčko Sestavit žádosti 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ří:

Pokud chcete obejít toto opatření v kanálech GitHubu, povolte zaškrtávací 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 Make mají stejná oprávnění jako běžná nastavení sestavení .

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

Centrálně můžete definovat, jak kanály sestavují žádosti o přijetí změn z rozvětvovaných úložišť GitHubu pomocí omezení vytváření žádostí o přijetí změn z ovládacího prvku forkovaných úložišť GitHub. Je k dispozici na úrovni organizace a projektu. Můžete zvolit, zda chcete:

  • 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šť

Screenshot of centralized control settings for how pipelines build PRs from forked GitHub repositories.

Od sprintu 229 už Azure Pipelines kvůli lepšímu zabezpečení vašich kanálů automaticky nevystavuje žádosti o přijetí změn z rozvětvovaných úložišť GitHubu. U nových projektů a organizací je výchozí hodnota omezení vytváření žádostí o přijetí změn z rozvětvovaných úložišť GitHubu zakázat vytváření žádostí o přijetí změn z forků úložišť.

Když zvolíte možnost Bezpečně sestavit žádosti o přijetí změn z forkovaných úložišť , nebudou všechny kanály, organizace nebo projektové úložiště moct zpřístupnit tajné kódy pro sestavení žádostí o přijetí změn z forkovaných úložišť, nemůžou mít tato sestavení stejná oprávnění jako běžná sestavení a musí být aktivována komentářem k žádosti o přijetí změn. Projekty se stále můžou rozhodnout, že kanály nebudou moct 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 kanály nebudou moct vytvářet takové žádosti o přijetí změn nebo je bezpečně sestavovat, nebo mají 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 ve výchozím nastavení zabezpečené sestavování žádostí o přijetí změn z rozvětvovaných úložišť.

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 zaškrtávací políčko Zpřístupnit tajné kódy pro sestavení forků , pokud je vaše úložiště veřejné nebo nedůvěryhodné uživatele může 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 autorům žádostí o přijetí změn důvěřujete.

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 a triggery. Potom v části Ověření žádosti o přijetí změn povolte před vytvořením žádosti o přijetí změn komentář Vyžadovat komentář člena týmu.
    • Zvolte Možnost Pro všechny žádosti o přijetí změn, pokud chcete před vytvořením žádosti 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, aby vyžadoval komentář člena týmu pouze v případech, kdy žádost o přijetí změn provádí 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 není vybráno pouze žádosti o přijetí změn od členů jiného týmu a žádost o přijetí změn provede člen týmu. Sestavení můžou aktivovat pouze vlastníci úložiště a spolupracovníci s oprávněním Zapisovat, a to tak, že k žádosti o přijetí změn zakomentují nebo /AzurePipelines run/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 místo /azp/AzurePipelines.

Důležité

Odpovědi na tyto příkazy se zobrazí v diskuzi o žádosti o přijetí změn jenom v případě, že váš kanál používá aplikaci 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 je vaše členství 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 z soukromého na veřejné zde (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.

Screenshot of an informational pipeline run.

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

Přečtěte si 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 checkout: none a pak pomocí úlohy skriptu provést vlastní rezervaci.

Upřednostňovaná verze Gitu

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

Cesta k pokladně

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

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

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

Submoduly

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

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

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

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

  • Ověřené:

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

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

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

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

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

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

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

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

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

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

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

Poznámka:

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

Synchronizovat značky

Důležité

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

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

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

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

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

steps:
- checkout: self
  fetchTags: true

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

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

    Screenshot of more triggers menu.

  2. Zvolte YAML, Získat zdroje.

    Screenshot of Get sources.

  3. Nakonfigurujte nastavení Synchronizovat značky.

    Screenshot of Sync tags setting.

Poznámka:

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

Výchozí chování

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

Poznámka:

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

Mělký fetch

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

Důležité

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

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

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

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

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

    Screenshot of more triggers menu.

  2. Zvolte YAML, Získat zdroje.

    Screenshot of Get sources.

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

    Screenshot of options.

Poznámka:

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

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

Nastavení Nesynchronizovat zdroje můžete nakonfigurovat v kroku Rezervace 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 ú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.

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

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

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

git clean -ffdx
git reset --hard HEAD

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

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

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

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

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

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

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

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

Configure Git options, YAML.

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

From the Classic editor, choose YAML > Get sources.

Ve formátu Značky 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é.

Předdefinované proměnné

Při vytváření úložiště GitHubu je většina předdefinovaných proměnných dostupná pro vaše úlohy. 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ů využívajících připojení PAT nebo 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 GitHub 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 tady.

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.

GitHub checks rerun

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šíření a zahrnutí šablon do 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 do výchozí větve pro ruční a plánované nastavení sestavení 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ě.

Často kladené dotazy

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

  • Připojení ionové typy: Nevím, jaký typ připojení používám k připojení kanálu k GitHubu.
  • Triggery, které selhávají: Kanál se neaktivuje, když do úložiště nasdílím aktualizaci.
  • Neúspěšná rezervace: Kanál se aktivuje, ale v kroku rezervace selže.
  • Nesprávná verze: Kanál se spustí, ale používá neočekávanou verzi zdrojového nebo YAML.
  • Chybějící aktualizace stavu: Moje žádosti o přijetí změn na GitHubu jsou blokované, protože Služba Azure Pipelines nenahlásila aktualizaci stavu.

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 triggerů otevřete klasický editor kanálu. Pak vyberte kartu YAML a pak krok Získat zdroje . Všimnete si banneru Autorizované pomocí připojení: označuje 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 indikuje připojení aplikace GitHub
    • Oauth indikuje připojení OAuth.
    • personalaccesstoken indikuje ověřování PAT.

Návody 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 na 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 https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)přejdete na stránku Pipelines (např. vyberete kanál a kliknete na Upravit).
  5. Pokud se jedná o kanál YAML, výběrem nabídky Triggers 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 téma Ověřování aplikací GitHubu.
  • Pokud používáte OAuth, přečtěte si téma Ověřování OAuth.
  • Pokud používáte paty, přečtěte si téma Ověř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 vytvořte 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ě:

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

    Pipeline settings UI.

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

    Override YAML trigger from here.

  • Používáte připojení aplikace GitHub k připojení kanálu k GitHubu? Pokud chcete určit typ připojení, které máte, podívejte se na typy Připojení ion. 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 vytvořte komentář /azp where. Tato sestava vrací organizaci Azure DevOps, na kterou je úložiště namapované.

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

      • 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, podívejte se na typy Připojení ion. 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í, které chcete zkontrolovat. Pokud je kanál pozastavený nebo zakázaný, triggery nefungují.

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

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

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

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

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

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

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

Nejprve si projděte kroky pro řešení potíží v předchozí otázce 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í:

    • Na naší stránce stavu dochází k výpadku služby. Pokud se na stránce stavu zobrazí problém, musí na ní náš tým už začít pracovat. Podívejte se na stránku, kde najdete časté aktualizace problému.
    • 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 mám postupovat?

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

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

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

Neúspěšná rezervace

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

remote: 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č?

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