Sestavení úložišť Bitbucket Cloud

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ě Bitbucket Cloud. Tento článek popisuje, jak nakonfigurovat integraci mezi Bitbucket Cloudem a Azure Pipelines.

Bitbucket a Azure Pipelines jsou dvě nezávislé služby, které se dobře integrují. Vaši uživatelé služby Bitbucket Cloud automaticky nezískali přístup ke službě Azure Pipelines. Musíte je explicitně přidat do Azure Pipelines.

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

YAML

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

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

Klasické

Nový kanál vytvoříte tak, že nejprve vyberete Bitbucket Cloud pro typ úložiště a pak jedno z úložišť, ke kterým máte přístup.

Aby bylo možné načíst kód během sestavení, musí být službě Azure Pipelines udělen přístup k vašim úložištím. Kromě toho musí mít uživatel, který nastavuje kanál, přístup správce k Bitbucketu, protože tato identita se používá k registraci webhooku v Bitbucketu.

Při vytváření kanálu existují 2 typy ověřování pro udělení přístupu ke cloudovým úložištím Bitbucket Azure Pipelines.

Authentication type	Kanály se spouštějí pomocí
1. OAuth	Vaše osobní identita Bitbucketu
2. Uživatelské jméno a heslo	Vaše osobní identita Bitbucketu

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 účtu Bitbucket. Aktualizace stavu Bitbucketu se budou provádět jménem vaší osobní identity Bitbucketu. Aby kanály dál fungovaly, musí mít přístup k úložišti stále aktivní.

Pokud chcete použít OAuth, přihlaste se k Bitbucketu při zobrazení výzvy při vytváření kanálu. Potom kliknutím na Autorizovat autorizaci s OAuth. Připojení OAuth se uloží do projektu Azure DevOps pro pozdější použití a použije se také v kanálu, který se vytváří.

Poznámka:

Maximální počet úložišť Bitbucket, která může uživatelské rozhraní Azure DevOps Services načíst, je 2 000.

Ověřování heslem

Aktualizace stavu buildů a Bitbucketu se budou provádět jménem vaší osobní identity. Aby buildy fungovaly dál, musí mít přístup k úložišti stále aktivní.

Pokud chcete vytvořit připojení k heslu, přejděte na připojení služeb v nastavení projektu Azure DevOps. Vytvořte nové připojení služby Bitbucket a zadejte uživatelské jméno a heslo pro připojení k vašemu úložišti Bitbucket Cloud.

Triggery CI

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

YAML

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

Větve

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

trigger:
- main
- releases/*

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

Poznámka:

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

Poznámka:

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

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

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

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

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

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

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

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

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

Důležité

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

Dávkové spuštění CI

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

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

Poznámka:

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

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

Poznámka:

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

Cesty

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

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

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

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

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

Poznámka:

V případě úložišť Bitbucket Cloud je použití branches syntaxe jediným způsobem, jak určit triggery značek. Syntaxe tags: není pro Bitbucket podporovaná.

Odhlášení z CI

Zakázání triggeru CI

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

# A pipeline with no CI trigger
trigger: none

Důležité

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

Klasické

Poznámka:

Proměnná Build.SourceVersionMessage nefunguje s úložišti Bitbucket, když se služba Batch změní v době, kdy probíhá sestavení.

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

Dávkové změny

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

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

Poznámka:

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

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

Filtry větví

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

Filtry cest

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

Tipy:

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

Příklad

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

Přeskočení CI pro jednotlivá 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.

YAML

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í master , 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 master) 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.

Každé nové spuštění sestaví nejnovější potvrzení ze zdrojové větve žádosti o přijetí změn. Liší se od toho, jak Azure Pipelines vytváří žádosti o přijetí změn v jiných úložištích (např. Azure Repos nebo GitHub), kde sestavuje potvrzení sloučení. Bitbucket bohužel nezpřístupňuje informace o potvrzení sloučení, které obsahuje sloučený kód mezi zdrojovými a cílovými větvemi žádosti o přijetí změn.

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, nahradí výchozí implicitní pr trigger a aktivuje kanál pouze do větví, které jsou explicitně nakonfigurované tak, aby byly zahrnuty.

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.

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

• Filtry cest nepodporují zástupné znaky.
• 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).

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

Můžete určit, jestli by další aktualizace žádosti o přijetí změn měly zrušit probíhající ověřování pro stejnou žádost o přijetí změn. Výchozí hodnota je true.

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

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, ujistěte se, že jste v uživatelském rozhraní nepřepsli aktivační události žádosti o přijetí změn YAML.

Klasické

Vyberte trigger ověření žádosti o přijetí změn a zaškrtněte políčko Povolit ověření žádosti o přijetí změn, abyste povolili sestavení na žádostech o přijetí změn.

Můžete zadat větve, které se mají zahrnout a vyloučit. V rozevírací nabídce vyberte název větve a podle potřeby vyberte Zahrnout nebo Vyloučit . U zahrnutých větví se při každém nasdílení změn do žádosti o přijetí změn, která cílí na danou větev, aktivuje sestavení.

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.

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.

Omezení

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í Bitbucketu spadají do následujících kategorií:

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

Neúspěšné triggery

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

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

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

  

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

  

• Webhooky se používají ke komunikaci aktualizací z Bitbucketu do Azure Pipelines. V Bitbucketu přejděte do nastavení úložiště a pak do webhooků. Ověřte, že webhooky existují.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.