Konfigurace rozvrhů pro potrubí

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

Azure Pipelines poskytuje několik typů spouštěčů pro nastavení spuštění vašeho kanálu.

• Naplánované triggery spouští potrubí podle harmonogramu, například při nočním sestavení. Tento článek obsahuje pokyny k používání plánovaných triggerů ke spouštění pipeline na základě harmonogramu.
• Spouště založené na událostech spouští potrubí v reakci na události, jako je například vytvoření pull requestu nebo push změn do větve. Informace o používání triggerů založených na událostech najdete v tématu Triggery ve službě Azure Pipelines.

V kanálech můžete kombinovat naplánované aktivační události a aktivační události založené na událostech, například pro ověření sestavení při každém odeslání změn (trigger CI), při vytvoření žádosti o přijetí změn (trigger PR) a pro noční sestavení (naplánovaná aktivační událost). Pokud chcete kanál sestavit jenom podle plánu, a ne v reakci na triggery založené na událostech, ujistěte se, že váš kanál nemá povolené žádné další triggery. Například potrubí YAML v úložišti GitHub mají ve výchozím nastavení povolené triggery CI a PR. Informace o zakázání výchozích triggerů najdete v tématu Triggery ve službě Azure Pipelines a přejděte do části, která se zabývá typem úložiště.

Naplánované spouště

YAML

Důležitý

Naplánované triggery definované pomocí uživatelského rozhraní nastavení kanálu mají přednost před plánovanými triggery YAML.

Pokud váš kanál YAML obsahuje naplánované triggery YAML i naplánované aktivační události definované uživatelským rozhraním, spustí se pouze naplánované aktivační události definované uživatelským rozhraním. Pokud chcete spustit naplánované triggery YAML definované v kanálu YAML, musíte odebrat naplánované triggery definované v uživatelském rozhraní nastavení kanálu. Jakmile se odeberou všechny naplánované triggery v uživatelském rozhraní, je nutné provést odeslání, aby se naplánované triggery v YAML začaly vyhodnocovat.

Pokud chcete odstranit naplánované triggery uživatelského rozhraní z kanálu YAML, podívejte se, jak nastavení v uživatelském rozhraní přepisuje naplánované triggery YAML .

Naplánované triggery konfigurují kanál tak, aby běžel podle plánu definovaného pomocí syntaxe cron.

schedules:
- cron: string # cron syntax defining a schedule
  displayName: string # friendly name given to a specific schedule
  branches:
    include: [ string ] # which branches the schedule applies to
    exclude: [ string ] # which branches to exclude from the schedule
  always: boolean # whether to always run the pipeline or only if there have been source code changes since the last successful scheduled run. The default is false.
  batch: boolean # Whether to run the pipeline if the previously scheduled run is in-progress; the default is false.
  # batch is available in Azure DevOps Server 2022.1 and higher

Naplánované kanály v YAML mají následující omezení.

• Časové pásmo pro plány cron je UTC. Pomocí AI z GitHub Copilot můžete vytvářet výrazy cron.
• Pokud zadáte klauzuli exclude bez klauzule include pro branches, je ekvivalentem určení * v klauzuli include.
• Nemůžete použít proměnné potrubí při nastavování plánů.
• Pokud v souboru YAML používáte šablony, musí být plány zadány v hlavním souboru YAML, a ne v souborech šablon.

Úvahy o větvích pro plánované spouště

Naplánované triggery se vyhodnocují pro větev, když dojde k následujícím událostem.

• Vytvoří se kanál.
• Soubor YAML potrubí se aktualizuje buď z push, nebo úpravou v editoru potrubí.
• Cesta k souboru YAML kanálu je aktualizována tak, aby odkazovala na jiný YAML soubor. Tato změna aktualizuje pouze výchozí větev, a proto pouze převezme plány v aktualizovaném souboru YAML pro výchozí větev. Pokud některé další větve následně sloučí výchozí větev, například git pull origin main, vyhodnocují se naplánované triggery z nově odkazovaného souboru YAML pro danou větev.
• Vytvoří se nová větev.

Po výskytu jedné z těchto událostí ve větvi se přidají všechna naplánovaná spuštění pro danou větev, pokud tato větev odpovídá filtrům větví pro naplánované triggery obsažené v souboru YAML v této větvi.

Důležitý

Naplánovaná spuštění pro větev se přidají pouze v případě, že větev odpovídá filtrům větví pro naplánované triggery v souboru YAML v této konkrétní větvi.

Kanál se například vytvoří s následujícím plánem a tato verze souboru YAML je vrácena do větve main. Každý den tento harmonogram vytváří větev main.

# YAML file in the main branch
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

Dále se vytvoří nová větev založená na mains názvem new-feature. Naplánované spouštěče ze souboru YAML v nové větvi se čtou, a protože pro větev new-feature neexistuje žádná shoda, neprovedou se žádné změny naplánovaných sestavení, a větev new-feature není sestavena pomocí naplánovaného spouštěče.

Pokud do seznamu branches přidáte new-feature a tato změna je přenesena do větve new-feature, soubor YAML se načte a protože new-feature je nyní v seznamu větví, přidá se plánované sestavení pro větev new-feature.

# YAML file in the new-feature-branch
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main
    - new-feature

Teď zvažte, že se vytvoří větev s názvem release, která je založená na maina pak se release přidá do filtrů větví v souboru YAML v main větvi, ale ne v nově vytvořené release větvi.

# YAML file in the release branch
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

# YAML file in the main branch with release added to the branches list
schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main
    - release

Protože release byly přidány do filtrů větví ve větvi main, ale nebyly přidány jako do filtrů větví ve větvi release, větev release nebude podle toho plánu postavena. Pouze když je větev release přidána do filtrů větví v YAML souboru na uvolněné větvi, bude naplánované sestavení přidáno do plánovače.

Aspekty služby Batch pro naplánované triggery

Vlastnost batch konfiguruje, jestli se má kanál spustit, pokud probíhá dříve naplánované spuštění. Pokud je batchtrue, nový běh pipeline nezačne podle plánu, pokud stále probíhá předchozí běh. Výchozí hodnota je false.

Vlastnost batch je ovlivněna nastavením vlastnosti always. Když je alwaystrue, proces se spustí podle plánu cron, i když batch je true a probíhá spuštění.

Vždy	Várka	Chování
false	false	Pipeline se spustí jen v případě, že dojde ke změně oproti poslednímu úspěšnému naplánovanému spuštění pipeline, i když probíhá spuštění z posledního naplánovaného spouštěče.
false	true	Kanál se spustí jenom v případě, že dojde ke změně ve srovnání s posledním úspěšným naplánovaným spuštěním a neprobíhá žádné naplánované spuštění kanálu.
true	false	Ropovod se spouští podle plánu cron.
true	true	Kanál se spouští podle plánu cron, i když probíhá probíhající spuštění.

Proměnná Build.CronSchedule.DisplayName

Když je kanál spuštěný kvůli naplánované aktivační události cron, předdefinovaná proměnná Build.CronSchedule.DisplayName obsahuje displayName plánu cron, který aktivoval spuštění kanálu.

Kanál YAML může obsahovat více plánů cron a vy můžete chtít, aby váš kanál spouštěl různé fáze nebo úlohy podle toho, které plány cron běží. Například máte noční build a týdenní build a chcete spustit určitou fázi pouze během nočního build. Proměnnou Build.CronSchedule.DisplayName v podmínce úlohy nebo fáze můžete použít k určení, jestli se má úloha nebo fáze spustit.

- stage: stage1
  # Run this stage only when the pipeline is triggered by the 
  # "Daily midnight build" cron schedule
  condition: eq(variables['Build.CronSchedule.DisplayName'], 'Daily midnight build')

Další příklady najdete v příkladech schedules.cron .

Vyberte dny a časy, kdy chcete sestavení spustit pomocí klasického editoru.

Pokud je vaším úložištěm Azure Repos Git, GitHub nebo jiný Git, můžete také určit, které větve mají být zahrnuty a které vyloučeny. Pokud chcete použít zástupné znaky, zadejte specifikaci větve (například features/modules/*) a stiskněte Enter.

Příklady

Následující příklad definuje dva plány:

schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/ancient/*
- cron: '0 12 * * 0'
  displayName: Weekly Sunday build
  branches:
    include:
    - releases/*
  always: true

První plán, denní sestavení půlnocí, spustí pipeline každou noc o půlnoci, ale pouze pokud se kód změnil od posledního úspěšného naplánovaného spuštění, pro main a všechny větve releases/*, s výjimkou těch, které jsou pod releases/ancient/*.

Druhý plán, nedělní týdenní sestavení, spustí pipeline v neděli v poledne, bez ohledu na to, zda se kód od posledního spuštění změnil nebo ne, pro všechny větve releases/*.

Poznámka

Časové pásmo pro plánování cron je UTC, takže v těchto příkladech probíhá sestavení v půlnoci a v poledne podle UTC.

Další příklady najdete v tématu Migrace z klasického editoru.

Klasický

Příklad: Noční sestavení úložiště Git ve více časových pásmech

V tomto příkladu má naplánovaná aktivační událost klasického editoru dvě položky, které vytvoří následující sestavení.

• Každé pondělí – pátek ve 3:00 ráno v časovém pásmu UTC+5:30 sestavte větve, které splňují kritéria pro filtrování větví features/india/*

  

• Od pondělí do pátku ve 3:00 (časové pásmo UTC-5) sestavte větve, které splňují kritéria filtru větví features/nc/*.

  

Příklad: Noční build s různými frekvencemi

Azure Pipelines a Azure DevOps 2019 Server

V tomto příkladu má naplánovaný trigger klasického editoru dvě položky, které vytvářejí následující sestavení.

• Každý den od pondělí do pátku ve 3:00 UTC se sestavují větve, které splňují kritéria filtru větví main a releases/*.

  

• Každou neděli v 3:00 UTC sestavte větev releases/lastversion, i když se zdroj nebo kanál nezměnil.

  

Syntaxe Cron

Každý výraz cron pro naplánovaný spouštěč v Azure Pipelines je výraz oddělený mezerou obsahující pět položek v následujícím pořadí. Výraz je uzavřený v jednoduchých uvozovkách '.

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Pole	Přijaté hodnoty
Zápis	0 až 59
Hodiny	0 až 23
Dny	1 až 31
Měsíce	1 až 12, celé anglické jméno, první tři písmena anglického jména
Dny v týdnu	0 až 6 (od neděle), celé anglické jméno, první tři písmena anglického jména

Hodnoty můžou být v následujících formátech.

Formát	Příklad	Popis
Zástupný znak	*	Odpovídá všem hodnotám pro toto pole.
Jedna hodnota	5	Určuje jednu hodnotu pro toto pole.
Oddělené čárkami	3,5,6	Určuje více hodnot pro toto pole. Více formátů lze kombinovat, například 1,3-6
Rozsahy	1-3	Inkluzivní rozsah hodnot pro toto pole
Intervaly	*/4 nebo 1-5/2	Intervaly odpovídající tomuto poli, například každou čtvrtou hodnotu nebo rozsah 1–5 s intervalem kroku 2

Příklad	Výraz Cron
Budování každé pondělí, středu, a pátek v 18:00.	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5nebo 0 18 * * 1-5/2
Sestavení každých 6 hodin	0 0,6,12,18 * * *, 0 */6 * * * nebo 0 0-18/6 * * *
Sestavení každých 6 hodin počínaje 9:00 ráno	0 9,15,21 * * * nebo 0 9-21/6 * * *

Další informace o formátech, které jsou podporovány, najdete v části Crontab Expression.

Vytvoření výrazu cron pomocí GitHub Copilotu

Pomoc s AI můžete získat z GitHub Copilotu k sestavení výrazů cron nebo můžete převést existující výrazy cron z místního časového pásma na UTC.

Plány cron služby Azure Pipelines jsou definovány ve standardu UTC, takže plány jako Build každé pondělí, středu a pátek v 18:00 se musí vytvořit pomocí syntaxe cron a převést z místního časového pásma na UTC.

Přizpůsobte následující výzvy k vytvoření výrazů cron nebo převod výrazů cron na UTC z časového pásma, které jste použili k vytvoření výrazů.

V následujícím příkladu je Copilot vyzván k vytvoření plánu UTC cron, který spustí sestavení každé pondělí, středu a pátek v 18:00 východního standardního času.

Build a UTC cron expression for Monday, Wednesday, and Friday at 6:00 PM Eastern Standard Time

Pokud už v místním časovém pásmu máte výraz cron, můžete požádat Copilot, aby ho převel na UTC. V tomto příkladu se plán cron sestaví každé pondělí, středu a pátek v 18:00 (0 18 * * Mon,Wed,Fri) Východní standardní čas se převede na UTC.

Convert the following cron expression from Eastern Standard Time to UTC: 0 18 * * Mon,Wed,Fri

Převod výrazu cron na UTC může vyžadovat změnu dnů v týdnu ve výrazu. V následujícím příkladu je Copilot vyzván k vytvoření UTC cron plánu pro sestavování od pondělí do pátku ve 12:30 středoevropského standardního času. Středoevropský standardní čas je před časem UTC, takže výsledný výraz začíná pozdě v neděli v noci místo počátku pondělí ráno a končí ve čtvrtek.

Build a UTC cron expression for Monday through Friday at 12:30 AM Central European Standard Time

Pokud chcete získat další podrobnosti o výrazu cron vygenerovaném copilotem, můžete požádat Copilot, aby ve výzvě poskytl vysvětlení vygenerovaného výrazu cron.

Build a UTC cron expression for Monday through Friday at 12:30 AM Central European Standard Time and explain the different parts of the cron expression

Copilot využívá AI, takže překvapení a chyby jsou možné. Další informace najdete v tématu Nejčastější dotazy k obecnému použití copilotu.

Klasické plány se definují pomocí grafického editoru místo syntaxe cron. Informace o definování klasických plánů naleznete v tématu Příklady.

Zobrazení naplánovaných běhů

Náhled nadcházejících plánovaných buildů si můžete prohlédnout tak, že v místní nabídce na stránce s podrobnostmi o pipeline vyberete možnost naplánovaná spuštění.

Důležitý

V zobrazení naplánovaných spuštění se zobrazují pouze procesy naplánované k běhu během sedmi dnů od aktuálního data. Pokud má plán Cron interval delší než 7 dní a další spuštění se naplánuje tak, aby se spustilo po sedmi dnech od aktuálního data, nezobrazí se v zobrazení Naplánovaná spuštění.

Po vytvoření nebo aktualizaci plánovaných spouštěčů je můžete ověřit v zobrazení naplánovaných spuštění.

Tento příklad zobrazuje plánovaná spuštění pro plán popsaný níže.

schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

Naplánovaná spuštění okno zobrazuje časy převedené do místního časového pásma nastaveného na počítači, který se používá k přístupu k portálu Azure DevOps. Tento příklad zobrazí snímek obrazovky pořízený v časovém pásmu EST.

Poznámka

Pokud aktualizujete plán pro spuštěný pipeline, zobrazení Naplánovaná spuštění se s novým plánem neaktualizuje, dokud se aktuálně spuštěný pipeline nedokončí.

Náhled nadcházejících plánovaných buildů si můžete prohlédnout tak, že na stránce s podrobnostmi pipeline zvolíte v místní nabídce možnost naplánovaná spuštění.

Po vytvoření nebo aktualizaci plánovaných triggerů je můžete pomocí tohoto zobrazení ověřit.

Běh i v případě, že nedošlo k žádným změnám kódu

Ve výchozím nastavení se vaše potrubí nespustí dle plánu, pokud od posledního úspěšného spuštění dle plánu nedošlo k žádným změnám kódu. Představte si například, že jste naplánovali spuštění potrubí každou noc ve 21:00. Během pracovních dnů nasdílíte do kódu různé změny. Proces běží podle plánu. Během víkendů neproděláte žádné změny kódu. Pokud od naplánovaného spuštění v pátek nedošlo k žádným změnám kódu, potrubí se během víkendu nespustí.

YAML

Pokud chcete vynutit spuštění kanálu i v případě, že neexistují žádné změny kódu, můžete použít klíčové slovo always.

schedules:
- cron: ...
  ...
  always: true

Pokud chcete nakonfigurovat naplánovaný pipeline tak, aby se build provedl jen v případě, že od posledního sestavení došlo ke změně, zkontrolujte naplánovat buildy pouze v případě, že došlo ke změně zdroje nebo pipeline.

Omezení počtu naplánovaných spuštění v pipelinech YAML

Existují určitá omezení, jak často můžete naplánovat spuštění kanálu. Tato omezení byla zavedena, aby se zabránilo zneužití prostředků Azure Pipelines, zejména agentů hostovaných Microsoftem. Omezení jsou:

• přibližně 1 000 spuštění na pipeline za týden
• 10 spuštění na kanál za 15 minut

Migrace z klasického editoru

Následující příklady ukazují, jak migrovat plány z klasického editoru do YAML.

• příklad : Noční sestavení úložiště Git ve více časových pásmech
• Příklad : Noční kompilace s různými frekvencemi

Příklad: Noční sestavení úložiště Git ve více časových pásmech

V tomto příkladu má naplánovaný trigger klasického editoru dvě položky, které vytvářejí následující sestavení.

• Každý den od pondělí do pátku ve 3:00 ráno (časové pásmo UTC + 5:30) vytvářejte větve, které splňují kritéria filtru větví features/india/*.

  

• Každé pondělí až pátek ve 3:00 ráno (v časovém pásmu UTC-5) sestavte větve, které splňují kritéria filtru větví features/nc/*.

  

Ekvivalentní naplánovaná aktivační událost YAML je:

schedules:
- cron: '30 21 * * Sun-Thu'
  displayName: M-F 3:00 AM (UTC + 5:30) India daily build
  branches:
    include:
    - /features/india/*
- cron: '0 8 * * Mon-Fri'
  displayName: M-F 3:00 AM (UTC - 5) NC daily build
  branches:
    include:
    - /features/nc/*

V prvním harmonogramu M-F 3:00 (UTC + 5:30) denní sestavení Indie, je syntaxe cron (mm HH DD MM DW) 30 21 * * Sun-Thu.

• Minuty a hodiny - 30 21 - To odpovídá 21:30 UTC (9:30 PM UTC). Vzhledem k tomu, že zadané časové pásmo v klasickém editoru je UTC + 5:30, potřebujeme odečíst 5 hodin a 30 minut od požadovaného času sestavení 3:00 ráno, abychom získali požadovaný čas UTC pro aktivaci YAML. Můžete získat pomoc s AI z GitHub Copilotu k vytvoření výrazu cron.
• Dny a měsíce jsou zadány jako zástupné znaky, protože tento plán neurčuje, že by měl běžet pouze v určitých dnech měsíce nebo v konkrétním měsíci.
• Dny v týdnu - Sun-Thu - kvůli převodu časového pásma, aby se naše buildy spustily ve 3:00 v časovém pásmu UTC + 5:30 (Indie), musíme je zadat v UTC čase již předchozí den. Mohli bychom také určit dny v týdnu jako 0-4 nebo 0,1,2,3,4.

V druhém plánu pondělí až pátek 3:00 (UTC - 5) NC denní build, syntaxe cron je 0 8 * * Mon-Fri.

• Minuty a hodiny - 0 8 - Toto se mapuje na 8:00 AM UTC. Vzhledem k tomu, že zadané časové pásmo v klasickém editoru je UTC - 5:00, musíme přičíst 5 hodin k požadovanému času sestavení v 3:00 AM, abychom získali odpovídající čas UTC pro specifikaci aktivační události YAML. Můžete získat pomoc AI od GitHub Copilot pro vytvoření cron výrazu.
• Dny a měsíce se zadávají jako zástupné znaky, protože tento plán neuvádí, že by měl běžet jen v určité dny měsíce nebo v určitých měsících.
• Dny v týdnu – Mon-Fri – protože převody časových pásem nepřesahují pro náš požadovaný plán více dnů v týdnu, nemusíme tady provádět žádné převody. Mohli bychom také určit dny v týdnu jako 1-5 nebo 1,2,3,4,5.

Důležitý

Časová pásma UTC v naplánovaných spouštěčích YAML nepočítají s letním časem.

Spropitné

Při použití 3písmenných dnů v týdnu a chcete rozsah více dní až do neděle, neděle by měla být považována za první den v týdnu, například pro plán půlnoci EST, od čtvrtka do neděle, je syntaxe cron 0 5 * * Sun,Thu-Sat.

Příklad: Noční build s různou frekvencí

V tomto příkladu má naplánovaný trigger klasického editoru dvě položky, které vytvářejí následující sestavení.

• Každé pondělí až pátek ve 3:00 UTC sestavte větve, které splňují kritéria filtru větví main a releases/*.

  

• Každou neděli v 3:00 UTC sestavte větev releases/lastversion, i když se zdroj nebo kanál nezměnil.

  

Ekvivalentní naplánovaná aktivační událost YAML je:

schedules:
- cron: '0 3 * * Mon-Fri'
  displayName: M-F 3:00 AM (UTC) daily build
  branches:
    include:
    - main
    - /releases/*
- cron: '0 3 * * Sun'
  displayName: Sunday 3:00 AM (UTC) weekly latest version build
  branches:
    include:
    - /releases/lastversion
  always: true

V prvním plánu je denní build M-F 3:00 (UTC), syntaxe cron je 0 3 * * Mon-Fri.

• Minuty a hodiny - 0 3 - To se mapuje na 3:00 AM UTC. Vzhledem k tomu, že zadané časové pásmo v klasickém editoru je UTC, nemusíme provádět převody časových pásem.
• Dny a měsíce se zadávají jako zástupné znaky, protože tento harmonogram neurčuje běh jen v určitých dnech měsíce nebo v určitém měsíci.
• Dny v týdnu – Mon-Fri – protože neexistuje žádný převod časového pásma, mapa dnů v týdnu přímo z klasického plánu editoru. Mohli bychom také zadat dny v týdnu jako 1,2,3,4,5.

Ve druhém plánu je nedělní sestavení nejnovější verzev 3:00 (UTC), syntaxe je cron 0 3 * * Sun.

• Minuty a hodiny - 0 3 - To se mapuje na 3:00 AM UTC. Vzhledem k tomu, že zadané časové pásmo v klasickém editoru je UTC, nemusíme provádět převody časových pásem.
• Dny a měsíce se zadávají jako zástupné znaky, protože tento plán nestanovuje běh pouze v určité dny měsíce nebo v určitý měsíc.
• Dny v týdnu – Sun – protože převody časových pásem nepřesahují pro náš požadovaný plán více dnů v týdnu, nemusíme tady provádět žádné převody. Mohli bychom také zadat dny v týdnu jako 0.
• Zadáváme také always: true, protože je naplánováno spuštění tohoto sestavení bez ohledu na to, jestli byl zdrojový kód aktualizován.

FAQ

• chci, aby pipeline běžel jen podle plánu, a ne v případě, že někdo odešle změnu do větve
• V souboru YAML jsem definoval plán. Ale nešlo to. Co se přihodilo?
• Plány YAML fungovaly dobře. Ale teď přestali pracovat. Jak to mám ladit?
• Kód se nezměnil, přesto se spustí naplánované sestavení. Proč?
• Na panelu Naplánovaná spuštění vidím plánované spuštění. V tu chvíli se ale nespustí. Proč?
• Plány definované v kanálu YAML fungují pro jednu větev, ale ne pro druhou. Jak to vyřeším?

Chci, aby moje sestava běžela jen podle plánu a ne když někdo upraví změnu do větve.

Pokud chcete, aby vaše potrubí běželo jen podle plánu a ne když někdo provede změnu do větve nebo sloučí změnu do hlavní větve, musíte v potrubí explicitně zakázat výchozí aktivační události CI a PR.

Pokud chcete zakázat výchozí triggery CI a PR, přidejte do YAML pipeline následující příkazy a ověřte, že jste nepřepsali triggery YAML pipeline s triggery uživatelského rozhraní.

trigger: none
pr: none

Další informace naleznete v pr definice a definice triggeru.

V souboru YAML jsem definoval plán. Ale nešlo to. Co se přihodilo?

• Zkontrolujte několik dalších spuštění, která pro váš kanál naplánovala služba Azure Pipelines. Tato běhy najdete tak, že ve vaší pipeline vyberete akci naplánovaná spuštění. Seznam je vyfiltrován tak, aby ukazoval jen několik nadcházejících spuštění během následujících dnů. Pokud to nesplňuje vaše očekávání, pravděpodobně se jedná o případ, že jste nesprávně zadali plán cron nebo nemáte plán definovaný ve správné větvi. Přečtěte si výše uvedené téma, ve které se dozvíte, jak nakonfigurovat plány. Znovu vyhodnocete syntaxi cron. Všechny časy pro plány cron jsou ve standardu UTC.

• Proveďte malou triviální změnu souboru YAML a nasdílejte ji do úložiště. Pokud při čtení plánů ze souboru YAML dříve došlo k nějakému problému, měli byste ho opravit.

• Pokud máte v uživatelském rozhraní definované nějaké plány, nebudou se vaše plány YAML respektovat. Ujistěte se, že nemáte žádné plány uživatelského rozhraní, tím, že přejdete do editoru vašeho potrubí a poté vyberete Triggery.

• Počet spuštění, která můžete naplánovat pro kanál, je omezený. Přečtěte si další informace o omezeních .

• Pokud kód neobsahuje žádné změny, nemusí azure Pipelines spouštět nová spuštění. Přečtěte si, jak toto chování přepsat.

Plány YAML fungovaly dobře. Ale teď přestali pracovat. Jak to mám ladit?

• Pokud jste nezadali always:true, nebude váš kanál naplánovaný, pokud nedojde k žádným aktualizacím kódu. Zkontrolujte, jestli nedošlo ke změnám kódu a jak jste nakonfigurovali plány.

• Existuje limit, kolikrát lze naplánovat váš pipeline. Zkontrolujte, jestli jste tyto limity překročili.

• Zkontrolujte, jestli někdo povolil v uživatelském rozhraní víc plánů. Otevřete editor pro váš pipeline a vyberte Triggery. Pokud definovali plány v uživatelském rozhraní, nebudou se vaše plány YAML respektovat.

• Zkontrolujte, jestli je proces pozastavený nebo zakázaný. Vyberte Nastavení pro váš datový tok.

• Zkontrolujte několik dalších spuštění, která pro váš kanál naplánovala služba Azure Pipelines. V potrubí můžete najít tato spuštění výběrem akce naplánovaná spuštění. Pokud nevidíte plány, které jste očekávali, proveďte malou triviální změnu souboru YAML a nasdílejte aktualizaci do úložiště. Tím by se měly plány znovu synchronizovat.

• Pokud používáte GitHub k ukládání svého kódu, je možné, že GitHub omezil Azure Pipelines, když se pokusil spustit nový běh. Zkontrolujte, jestli můžete spustit nové spuštění ručně.

Kód se nezměnil, ale naplánované sestavení se spustí. Proč?

• Možná jste povolili možnost vždy spustit naplánované sestavení, i když nedošlo k žádným změnám kódu. Pokud používáte soubor YAML, ověřte syntaxi plánu v souboru YAML. Pokud používáte klasické kanály, ověřte, jestli jste v naplánovaných aktivačních událostech zaškrtnuli tuto možnost.

• Možná jste aktualizovali sestavovací potrubí nebo nějakou vlastnost potrubí. To způsobí naplánování nového spuštění, i když jste zdrojový kód neaktualizovali. Pomocí klasického editoru ověřte historii změn v kanálu.

• Možná jste aktualizovali připojení služby použité k připojení k úložišti. To způsobí naplánování nového spuštění, i když jste zdrojový kód neaktualizovali.

• Azure Pipelines nejprve zkontroluje, jestli kód obsahuje nějaké aktualizace. Pokud Azure Pipelines nedokáže navázat spojení s vaším úložištěm nebo získat tyto informace, vytvoří informační běh. Jedná se o testovací build, který vám dá vědět, že služba Azure Pipelines nemůže dosáhnout vašeho úložiště.

• Váš kanál nemusí mít úplně úspěšné sestavení. Pokud chcete zjistit, jestli chcete naplánovat nové sestavení, Azure DevOps vyhledá poslední zcela úspěšné naplánované sestavení. Pokud se žádné nenajde, spustí se nové naplánované sestavení. Částečně úspěšné naplánované buildy se nepovažují za úspěšné, takže pokud váš kanál obsahuje jenom částečně úspěšné sestavení, Azure DevOps aktivuje naplánované buildy, i když se váš kód nezměnil.

Na panelu Naplánovaná spuštění se zobrazuje naplánované spuštění. V té době se ale nespustí. Proč?

• Panel Potenciální rozvrhy zobrazuje všechny možné plány. Pokud jste ale nepronesli skutečné aktualizace kódu, nemusí se ve skutečnosti spouštět. Pokud chcete vynutit, aby se plán vždy spustil, ujistěte se, že jste nastavili vždy vlastnost v kanálu YAML, nebo zaškrtněte možnost vždy spustit v klasickém kanálu.

Plány definované v kanálu YAML fungují pro jednu větev, ale ne pro druhou. Jak to vyřeším?

Plány jsou definovány v souborech YAML a tyto soubory jsou přidruženy ke větvím. Pokud chcete, aby byl proces naplánován pro konkrétní větev, řekněme features/X, ujistěte se, že soubor YAML v této větvi má definovaný plán cron a že zahrnuje správné větve pro plánování. Soubor YAML ve větvi features/X by měl mít v tomto příkladu následující schedule:

schedules: 
- cron: '0 12 * * 0'   # replace with your schedule
  branches: 
    include: 
    - features/X  

Další informace najdete v tématu Aspekty větve pro plánované spouštěče.