Konfigurace plánů pro kanály

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

Azure Pipelines poskytuje několik typů triggerů pro konfiguraci spuštění kanálu.

• Naplánované triggery spouští kanál podle plánu, jako je například noční sestavení. Tento článek obsahuje pokyny k používání plánovaných triggerů ke spouštění kanálů na základě plánu.
• Triggery založené na událostech spouští kanál v reakci na události, jako je například vytvoření žádosti o přijetí změn nebo nasdílení 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é triggery a triggery založené na událostech, například k ověření sestavení při každém nasdílení změn (trigger CI), kdy se vytvoří žádost o přijetí změn (trigger žádosti o přijetí změn) a 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 kanály YAML v úložišti GitHub mají ve výchozím nastavení povolené triggery CI a triggery 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é triggery

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 kanál YAML obsahuje plánované triggery YAML i plánované triggery definované v uživatelském rozhraní, spouštějí se jenom plánované triggery definované uživatelským rozhraním. Pokud chcete v kanálu YAML spouštět plánované triggery definované v YAML, musíte odebrat plánované triggery definované v uživatelském rozhraní s nastavením kanálu. Jakmile se odeberou všechny naplánované triggery uživatelského rozhraní, je nutné provést nabízení, aby se naplánované triggery YAML začaly vyhodnocovat.

Pokud chcete odstranit naplánované triggery uživatelského rozhraní z kanálu YAML, přečtěte si téma Nastavení uživatelského rozhraní, které 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.
• Pokud zadáte klauzuli exclude bez include klauzule pro branches, je ekvivalentní k určení * v klauzuli include .
• Proměnné kanálu nemůžete použít při zadávání plánů.
• Pokud v souboru YAML používáte šablony, musí být plány zadány v hlavním souboru YAML, nikoli v souborech šablon.

Důležité informace o větvích pro plánované triggery

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

• Vytvoří se kanál.
• Soubor YAML kanálu se aktualizuje buď z nabízeného oznámení, nebo úpravou v editoru kanálu.
• Cesta k souboru YAML kanálu se aktualizuje tak, aby odkazovat na jiný soubor YAML. 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é jiné větve následně sloučí výchozí větev, například git pull origin mainnaplánované triggery z nově odkazovaného souboru YAML se vyhodnotí 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í jenom v případě, že větev odpovídá filtrům větví pro naplánované triggery v souboru YAML v dané větvi.

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

# 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 pojmenovaném mainnew-feature. Naplánované triggery ze souboru YAML v nové větvi se načtou a vzhledem k tomu, že pro větev není žádná shoda new-feature , neprovedou se žádné změny naplánovaných sestavení a new-feature větev není sestavená pomocí naplánované aktivační události.

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

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

Teď zvažte, že je pojmenovaná release větev vytvořena na základě a mainpak release se přidá do filtrů větví v souboru YAML ve 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 byla přidána do filtrů větví ve main větvi, ale ne do filtrů větví ve release větvi, release nebude tato větev postavena na daném plánu. Pouze když se release větev přidá do filtrů větví v souboru YAML ve větvi vydané verze, bude naplánované sestavení přidáno do plánovače.

Aspekty služby Batch pro naplánované triggery

Vlastnost batch konfiguruje, zda se má kanál spustit, pokud probíhá dříve naplánované spuštění; výchozí hodnota je false. To platí bez ohledu na verzi úložiště kanálu.

Následující tabulka popisuje, jak always a batch jak pracovat.

Always	Batch	Chování
false	false	Kanál se spustí jenom v případě, že dojde ke změně s ohledem na poslední úspěšné naplánované spuštění kanálu.
false	true	Kanál se spustí jenom v případě, že dojde ke změně s ohledem na poslední úspěšné naplánované spuštění kanálu a neprobíhá probíhající naplánované spuštění kanálu.
true	false	Kanál se spouští podle plánu cron.
true	true	Kanál se spouští podle plánu cron.

Důležité

Když always je true, kanál běží podle plánu cron, i když batch je true.

Proměnná Build.CronSchedule.DisplayName

Když je kanál spuštěný kvůli naplánované aktivační události cron, předdefinovaná Build.CronSchedule.DisplayName proměnná obsahuje displayName plán 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 sestavení. 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.

Klasické

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

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

Příklady

YAML

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í půlnoc sestavení, spustí kanál o půlnoci každý den, ale pouze v případě, že se kód změnil od posledního úspěšného naplánovaného spuštění, pro main a všechny releases/* větve s výjimkou větví v části releases/ancient/*.

Druhý plán , týdenní neděle sestavení, spustí kanál v poledne v neděli, ať už se kód od posledního spuštění změnil nebo ne, pro všechny releases/* větve.

Poznámka:

Časové pásmo pro plány cron je UTC, takže v těchto příkladech je půlnoc sestavení a poledne sestavení jsou o půlnoci a poledne v 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 v 3:00 (UTC + 5:30 časové pásmo), větve sestavení, které splňují features/india/* kritéria filtru větví

  

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

  

Příklad: Noční sestavení 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é pondělí – pátek v 3:00 UTC, sestavte větve, které splňují mainreleases/* kritéria filtru a větve.

  

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

  

Syntaxe Cron

YAML

Každý výraz cron naplánovaného triggeru Azure Pipelines je výraz oddělený mezerami s pěti položkami 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řípustné hodnoty
V řádu minut	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
Divoká karta	*	Odpovídá všem hodnotám pro toto pole.
Jedna hodnota	5	Určuje jednu hodnotu pro toto pole.
Čá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
Sestavení každé pondělí, středy a pátku v 18:00	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5 nebo 0 18 * * 1-5/2
Sestavení každých 6 hodin	0 0,6,12,18 * * *nebo 0 */6 * * *0 0-18/6 * * *
Sestavení každých 6 hodin od 9:00	0 9,15,21 * * * nebo 0 9-21/6 * * *

Další informace o podporovaných formátech naleznete v tématu Crontab Expression.

Klasické

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

Zobrazení naplánovaných spuštění

YAML

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 podrobností kanálu zvolíte Naplánovaná spuštění.

Důležité

V zobrazení naplánovaných spuštění se zobrazují jenom kanály naplánované tak, aby běžely do sedmi dnů od aktuálního data. Pokud má plán Cron interval delší než 7 dní a další spuštění se plánuje spustit po sedmi dnech od aktuálního data, nezobrazí se v zobrazení naplánovaných spuštění.

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

Tento příklad zobrazuje naplánovaná spuštění pro následující plán.

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

V oknech Naplánovaná spuštění se zobrazují časy převedené na místní časové pásmo nastavené na počítači použitém k přechodu na portál Azure DevOps. Tento příklad zobrazí snímek obrazovky pořízený v časovém pásmu EST.

Klasické

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 podrobností kanálu zvolíte Naplánovaná spuštění.

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

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

Ve výchozím nastavení se kanál nespustí podle plánu, pokud od posledního úspěšného naplánovaného spuštění nedošlo k žádným změnám kódu. Představte si například, že jste naplánovali spuštění kanálu každou noc v 9:00. Během pracovních dnů nasdílíte do kódu různé změny. Kanál se spouští 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, kanál se během víkendu nespustí podle plánu.

YAML

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

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

Klasické

Pokud chcete nakonfigurovat naplánovaný kanál tak, aby se buildoval jenom v případě, že došlo ke změně od posledního sestavení, zkontrolujte , jestli nedošlo ke změně zdroje nebo kanálu.

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

Pro frekvenci plánovaného spouštění kanálu platí určitá omezení. Používané limity mají za cíl zabránit zneužití prostředků služby Azure Pipelines, zejména agentů hostovaných Microsoftem. Platné limity:

• přibližně 1000 spuštění kanálu za týden
• 10 spuštění kanálu 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í sestavení 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é pondělí – pátek v 3:00 (UTC + 5:30 časové pásmo), větve sestavení, které splňují features/india/* kritéria filtru větví

  

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

  

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 plánu M-F 3:00 (UTC + 5:30) Indie denní sestavení, syntaxe cron (mm HH DD MM DW) je 30 21 * * Sun-Thu.

• Minuty a hodiny – 30 21 to se mapuje na 21:30 UTC (9:30 PM UTC). Vzhledem k tomu, že zadané časové pásmo v klasickém editoru je UTC + 5:30, musíme odečíst 5 hodin a 30 minut od požadovaného času sestavení 3:00, aby bylo možné zadat požadovaný čas UTC pro trigger YAML.
• Dny a měsíce se zadávají jako zástupné dny, protože tento plán nezadá, aby běžel jenom v určitých dnech v měsíci nebo v určitém měsíci.
• Dny v týdnu – Sun-Thu kvůli převodu časového pásma musí naše buildy běžet v 3:00 v časovém pásmu UTC + 5:30 Indie, musíme je zadat od předchozího dne v čase UTC. Mohli bychom také určit dny v týdnu jako 0-4 nebo 0,1,2,3,4.

V druhém plánu je syntaxe 0 8 * * Mon-Fricron 3:00 (UTC - 5) NC denní sestavení nc .

• Minuty a hodiny - 0 8 to 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řidat 5 hodin od požadovaného času sestavení 3:00, aby se dostavil požadovaný čas UTC, abychom určili aktivační událost YAML.
• Dny a měsíce se zadávají jako zástupné dny, protože tento plán nezadá, aby běžel jenom v určitých dnech v měsíci nebo v určitém měsíci.
• Dny v týdnu – Mon-Fri protože naše převody časových pásem nepřesahují více dnů v týdnu pro požadovaný plán, 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 triggerech YAML nepočítá s letním časem.

Tip

Při použití 3 písmena v týdnu a chcete rozsah více dní až Slunce, sun by se měl považovat za první den v týdnu, například pro plán půlnoci EST, čtvrtek do neděle, syntaxe cron je 0 5 * * Sun,Thu-Sat.

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

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í – pátek v 3:00 UTC, sestavte větve, které splňují mainreleases/* kritéria filtru a větve.

  

• Každou neděli v 3:00 UTC sestavte releases/lastversion větev, 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 0 3 * * Mon-Frisyntaxe cron syntaxe M-F 3:00 (UTC) denně .

• 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 žádné převody časových pásem.
• Dny a měsíce se zadávají jako zástupné dny, protože tento plán nezadá, aby běžel jenom v určitých dnech v měsíci 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, neděle 3:00 (UTC) týdenní nejnovější verze sestavení, syntaxe cron je 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 žádné převody časových pásem.
• Dny a měsíce se zadávají jako zástupné dny, protože tento plán nezadá, aby běžel jenom v určitých dnech v měsíci nebo v určitém měsíci.
• Dny v týdnu – Sun protože naše převody časových pásem nepřesahují více dnů v týdnu pro požadovaný plán, nemusíme tady provádět žádné převody. Mohli bychom také zadat dny v týdnu jako 0.
• Také určíme always: true , že je toto sestavení naplánované tak, aby se spustilo, jestli byl zdrojový kód aktualizován nebo ne.

Často kladené dotazy

• Chci, aby kanál běžel jenom podle plánu, a ne v případě, že někdo nasdílí změnu do větve
• V souboru YAML jsem definoval plán. Ale nešlo to. Co se stalo?
• Plány YAML fungovaly dobře. Ale teď přestali pracovat. Návody to ladit?
• Kód se nezměnil, ale naplánované sestavení se aktivuje. Proč?
• Na panelu Naplánovaná spuštění se zobrazuje naplá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 můžu vyřešit?

Chci, aby kanál běžel jenom podle plánu, a ne v případě, že někdo nasdílí změnu do větve

Pokud chcete, aby váš kanál běžel jenom podle plánu, a ne když někdo nasdílí změnu do větve nebo sloučí změnu do hlavní větve, musíte v kanálu 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 kanálu YAML následující příkazy a ověřte, že jste nepřepsali triggery kanálu YAML pomocí triggerů uživatelského rozhraní.

trigger: none
pr: none

Další informace najdete v definici žádosti o přijetí změn a definici triggeru.

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

• Zkontrolujte několik dalších spuštění, která pro váš kanál naplánovala služba Azure Pipelines. Tato spuštění najdete tak , že v kanálu vyberete akci Naplánovaná spuštění . Seznam se vyfiltruje tak, aby zobrazoval jen nadcházející několik spuštění za několik příští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í, a to tak, že přejdete do editoru pro váš kanál a 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 limitech.

• 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. Návody to ladit?

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

• Existuje limit, kolikrát můžete naplánovat kanál. 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 kanálu a vyberte Aktivační události. Pokud definovali plány v uživatelském rozhraní, nebudou se vaše plány YAML respektovat.

• Zkontrolujte, jestli je kanál pozastavený nebo zakázaný. Vyberte Nastavení pro váš kanál.

• Zkontrolujte několik dalších spuštění, která pro váš kanál naplánovala služba Azure Pipelines. Tato spuštění najdete tak , že v kanálu vyberete akci 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 ke ukládání kódu používáte GitHub, je možné, že GitHub při pokusu o spuštění nového spuštění omezil Službu Azure Pipelines. Zkontrolujte, jestli můžete spustit nové spuštění ručně.

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

• Možná jste povolili možnost vždy spouštět 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 kanál buildu nebo nějakou vlastnost kanálu. 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 se Azure Pipelines nemůže spojit s vaším úložištěm nebo získat tyto informace, vytvoří informační spuštění. Jedná se o fiktivní build, který vám dá vědět, že Se službou Azure Pipelines se nemůže spojit s vaším úložištěm.

• 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 ho nenajdete, aktivuje 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 tu chvíli se ale nespustí. Proč?

• Na panelu Naplánovaná spuštění se zobrazují všechny potenciální 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 v kanálu YAML nastavili vždy vlastnost, 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 můžu vyřešit?

Plány jsou definovány v souborech YAML a tyto soubory jsou přidruženy ke větvím. Pokud chcete, aby byl kanál naplánovaný pro určitou větev, řekněme features/X, ujistěte se, že soubor YAML v této větvi má definovaný plán cron a že obsahuje správné zahrnutí větví pro plán. Soubor YAML ve větvi by měl mít v tomto příkladu features/X 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é triggery.