Planningen voor pijplijnen configureren

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure Pipelines biedt verschillende typen triggers om te configureren hoe uw pijplijn wordt gestart.

• Geplande triggers starten uw pijplijn volgens een schema, zoals een nachtelijke build. Dit artikel biedt richtlijnen voor het gebruik van geplande triggers om uw pijplijnen volgens een schema uit te voeren.
• Triggers op basis van gebeurtenissen starten uw pijplijn als reactie op gebeurtenissen, zoals bijvoorbeeld het maken van een pull request of het pushen naar een tak. Zie Triggers in Azure Pipelinesvoor meer informatie over het gebruik van triggers op basis van gebeurtenissen.

U kunt geplande en gebeurtenisgebaseerde triggers in uw pijplijnen combineren, bijvoorbeeld om de build te valideren telkens wanneer een push wordt uitgevoerd (CI-trigger), wanneer er een pull-aanvraag wordt gedaan (PR-trigger) en een nachtbuild (geplande trigger). Als u uw pijplijn alleen wilt bouwen volgens een planning en niet als reactie op triggers op basis van gebeurtenissen, moet u ervoor zorgen dat uw pijplijn geen andere triggers heeft ingeschakeld. YAML-pijplijnen in een GitHub-opslagplaats hebben bijvoorbeeld STANDAARD CI-triggers en PR-triggers ingeschakeld. Zie voor meer informatie over het uitschakelen van standaardtriggers Triggers in Azure Pipelines en navigeer naar de sectie die betrekking heeft op het type opslagplaats.

Geplande triggers

YAML

Belangrijk

Geplande triggers die zijn gedefinieerd met behulp van de gebruikersinterface voor pijplijninstellingen hebben voorrang op yamL-geplande triggers.

Als uw YAML-pijplijn zowel geplande YAML-triggers als door de gebruikersinterface gedefinieerde geplande triggers bevat, worden alleen de door de gebruikersinterface gedefinieerde geplande triggers uitgevoerd. Als u de door YAML gedefinieerde geplande triggers in uw YAML-pijplijn wilt uitvoeren, moet u de geplande triggers verwijderen die zijn gedefinieerd in de gebruikersinterface voor pijplijninstellingen. Zodra alle geplande triggers voor de gebruikersinterface zijn verwijderd, moet er een push worden uitgevoerd om de YAML-geplande triggers te laten evalueren.

Zie voor het verwijderen van geplande triggers uit een YAML-pijplijn UI-instellingen overschrijven YAML-geplande triggers.

Geplande triggers configureren een pijplijn voor uitvoering volgens een schema dat is gedefinieerd met cron-syntaxis.

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

Geplande pijplijnen in YAML hebben de volgende beperkingen.

• De tijdzone voor cron-schema's is UTC. U kunt AI-hulp krijgen van GitHub Copilot om uw cron-expressies te maken.
• Als u een exclude-component opgeeft zonder een include-component voor branches, is dit gelijk aan het opgeven van * in de include-component.
• U kunt geen pijplijnvariabelen gebruiken bij het opgeven van planningen.
• Als u sjablonen in uw YAML-bestand gebruikt, moeten de planningen worden opgegeven in het hoofd-YAML-bestand en niet in de sjabloonbestanden.

Overwegingen met betrekking tot vertakkingen voor geplande triggers

Geplande triggers worden geëvalueerd voor een tak wanneer de volgende gebeurtenissen plaatsvinden.

• Er wordt een pijplijn gemaakt.
• Het YAML-bestand van een pijplijn wordt bijgewerkt hetzij door een push, hetzij door het te bewerken in de pijplijneditor.
• Het YAML-bestandspad van een pijplijn wordt bijgewerkt om te verwijzen naar een ander YAML-bestand. Met deze wijziging wordt alleen de standaardbranch bijgewerkt en worden daarom alleen planningen opgehaald in het bijgewerkte YAML-bestand voor de standaardbranch. Als andere vertakkingen vervolgens de standaardbranch samenvoegen, bijvoorbeeld git pull origin main, worden de geplande triggers uit het zojuist verwezen YAML-bestand geëvalueerd voor die vertakking.
• Er wordt een nieuwe tak gemaakt.

Nadat een van deze gebeurtenissen in een vertakking plaatsvindt, worden geplande uitvoeringen voor die vertakking toegevoegd als die vertakking overeenkomt met de vertakkingsfilters voor de geplande triggers die zijn opgenomen in het YAML-bestand in die vertakking.

Belangrijk

Geplande runs voor een branch worden alleen toegevoegd als de branch overeenkomt met de branchesfilters voor de geplande triggers in het YAML-bestand van die specifieke branch.

Er wordt bijvoorbeeld een pijplijn gemaakt met het volgende schema, en deze versie van het YAML-bestand wordt ingecheckt in de main tak. Met dit schema wordt de main branch dagelijks gebouwd.

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

Vervolgens wordt een nieuwe tak aangemaakt op basis van main, met de naam new-feature. De geplande triggers uit het YAML-bestand in de nieuwe vertakking worden gelezen en omdat er geen overeenkomst is voor de new-feature vertakking, worden er geen wijzigingen aangebracht in de geplande builds en wordt de new-feature vertakking niet gebouwd met behulp van een geplande trigger.

Als new-feature wordt toegevoegd aan de branches lijst en deze wijziging naar de new-feature vertakking wordt gepusht, wordt het YAML-bestand gelezen en omdat new-feature nu in de lijst met vertakkingen staat, wordt er een geplande build toegevoegd voor de new-feature vertakking.

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

Overweeg nu dat een vertakking met de naam release is gemaakt op basis van mainen vervolgens release wordt toegevoegd aan de vertakkingsfilters in het YAML-bestand in de main vertakking, maar niet in de zojuist gemaakte release vertakking.

# 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

Omdat release is toegevoegd aan de vertakkingsfilters in de main vertakking, maar niet aan de vertakkingsfilters in de release vertakking, zal de release vertakking niet volgens die planning worden gebouwd. Alleen wanneer de release vertakking wordt toegevoegd aan de vertakkingsfilters in het YAML-bestand in de releasebranch wordt de geplande build toegevoegd aan de scheduler.

Overwegingen voor batchverwerking van geplande triggers

De eigenschap batch configureert of de pijplijn moet worden uitgevoerd als de eerder geplande taak nog bezig is. Wanneer batch is true, start een nieuwe pijplijnuitvoering niet volgens het schema indien een eerdere pijplijnuitvoering nog bezig is. De standaardwaarde is false.

De eigenschap batch wordt beïnvloed door de instelling van de eigenschap always. Wanneer always is true, wordt de pijplijn uitgevoerd volgens het cron-schema, zelfs wanneer batch is true en er een uitvoering aan de gang is.

Altijd	Batch	Gedrag
false	false	De pijplijn wordt alleen uitgevoerd als er een wijziging is ten opzichte van de laatste geslaagde geplande uitvoering, zelfs als er nog een uitvoering loopt van de laatste geplande trigger.
false	true	De pijplijn wordt alleen uitgevoerd als er een wijziging is ten opzichte van de laatste geslaagde geplande pijplijnuitvoering en er geen lopende geplande pijplijnuitvoering is.
true	false	De pijplijn loopt volgens het cron-tijdschema.
true	true	Pijplijnuitvoeringen volgens het cron-schema, zelfs als er een actieve uitvoering is.

Variabele "Build.CronSchedule.DisplayName"

Wanneer een pijplijn wordt uitgevoerd vanwege een geplande cron-trigger, bevat de vooraf gedefinieerde Build.CronSchedule.DisplayName variabele de displayName van het cron-schema dat de pijplijnuitvoering heeft geactiveerd.

Uw YAML-pijplijn kan meerdere cron-planningen bevatten en mogelijk wilt u dat uw pijplijn verschillende fasen of taken uitvoert op basis van de cron-planning. U hebt bijvoorbeeld een nachtbouw en een wekelijkse build en u wilt alleen een bepaalde fase uitvoeren tijdens de nachtbouw. U kunt de variabele Build.CronSchedule.DisplayName in een taak- of fasevoorwaarde gebruiken om te bepalen of die taak of fase moet worden uitgevoerd.

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

Zie schedules.cron-voorbeeldenvoor meer voorbeelden.

klassieke

Selecteer de dagen en tijden waarop u de build wilt uitvoeren met behulp van de klassieke editor.

Als uw opslagplaats Azure Repos Git, GitHub of een andere Git is, kunt u ook vertakkingen opgeven die moeten worden opgenomen en uitgesloten. Als u jokertekens wilt gebruiken, typt u de vertakkingsspecificatie (bijvoorbeeld features/modules/*) en drukt u op Enter.

Voorbeelden

YAML

In het volgende voorbeeld worden twee planningen gedefinieerd:

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

Het eerste schema, Dagelijkse middernacht-build, voert elke dag een pijplijn uit om middernacht, maar alleen als de code is gewijzigd sinds de laatste geslaagde geplande uitvoering, voor main en alle releases/* vertakkingen, met uitzondering van de vertakkingen onder releases/ancient/*.

In het tweede schema , Wekelijkse zondagse build, wordt op zondagmiddag een pijplijn uitgevoerd, ongeacht of de code sinds de laatste uitvoering is gewijzigd, voor alle releases/* vertakkingen.

Notitie

De tijdzone voor cron-schema's is UTC, dus in deze voorbeelden zijn de builds om middernacht en om twaalf uur 's middags in UTC.

Zie Migreren vanuit de klassieke editorvoor meer voorbeelden.

Klassiek

Voorbeeld: Nightly build van Git-repo in meerdere tijdzones

In dit voorbeeld bevat de geplande trigger van de klassieke editor twee vermeldingen, die de volgende builds produceren.

• Elke maandag tot en met vrijdag om 3:00 uur (tijdzone UTC + 5:30), bouw vertakkingen die aan de features/india/*-vertakkingsfiltercriteria voldoen

  

• Elke maandag tot en met vrijdag om 3:00 uur (UTC-5:00), maak vertakkingen die voldoen aan de features/nc/*-filtercriteria.

  

Voorbeeld: Nachtbouw met verschillende frequenties

Azure Pipelines en Azure DevOps 2019 Server

In dit voorbeeld bevat de geplande trigger van de klassieke editor twee vermeldingen, waardoor de volgende builds worden geproduceerd.

• Elke maandag tot en met vrijdag om 3:00 uur UTC worden vertakkingen gebouwd die aan de main- en releases/* vertakkingscriteria voldoen.

  

• Elke zondag om 3:00 uur UTC, bouw de releases/lastversion branch, zelfs als de bron of pijplijn niet is gewijzigd.

  

Cron-syntaxis

Elke geplande Cron-expressie voor triggers in Azure Pipelines is een expressie met spatiescheidingstekens met vijf vermeldingen in de volgende volgorde. De expressie wordt tussen enkele aanhalingstekens 'geplaatst.

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

Veld	Geaccepteerde waarden
Notulen	0 tot en met 59
Uren	0 tot en met 23
Dagen	1 tot en met 31
Maanden	1 tot en met 12, volledige Engelse namen, eerste drie letters van Engelse namen
Dagen van de week	0 tot en met 6 (vanaf zondag), volledige Engelse namen, eerste drie letters van Engelse namen

Waarden kunnen de volgende indelingen hebben.

Formaat	Voorbeeld	Beschrijving
Jokerteken	*	Komt overeen met alle waarden voor dit veld
Eén waarde	5	Hiermee geeft u één waarde voor dit veld
Door komma's gescheiden	3,5,6	Hiermee geeft u meerdere waarden voor dit veld op. Meerdere indelingen kunnen worden gecombineerd, zoals 1,3-6
Bereiken	1-3	Het inclusieve waardenbereik voor dit veld
Intervallen	*/4 of 1-5/2	Intervallen die overeenkomen met dit veld, zoals elke vierde waarde of het bereik 1-5 met een interval van 2

Voorbeeld	Cron-expressie
Bouw elke maandag, woensdag en vrijdag om 18:00 uur	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5of 0 18 * * 1-5/2
Elke 6 uur bouwen	0 0,6,12,18 * * *, 0 */6 * * * of 0 0-18/6 * * *
Bouw elke 6 uur vanaf 9:00 uur	0 9,15,21 * * * of 0 9-21/6 * * *

Zie Crontab Expressionvoor meer informatie over ondersteunde indelingen.

GitHub Copilot gebruiken om een cron-expressie te maken

U kunt AI-hulp krijgen van GitHub Copilot om cron-expressies te bouwen of bestaande cron-expressies van uw lokale tijdzone te converteren naar UTC.

Cron-planningen voor Azure Pipelines worden gedefinieerd in UTC. Planningen zoals Elke maandag, woensdag en vrijdag om 18:00 uur moeten worden gemaakt met behulp van cron-syntaxis en worden geconverteerd van uw lokale tijdzone naar UTC.

Pas de volgende prompts aan om cron-expressies te maken of converteer cron-expressies naar UTC vanuit de tijdzone die u hebt gebruikt om de expressies te maken.

In het volgende voorbeeld wordt Copilot gevraagd om een UTC cron-schema te maken om elke maandag, woensdag en vrijdag om 18:00 uur (Eastern Standaardtijd) een taak uit te voeren.

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

Als u al een cron-expressie in uw lokale tijdzone hebt, kunt u Copilot vragen deze te converteren naar UTC. In dit voorbeeld wordt een cron-planning om elke maandag, woensdag en vrijdag om 18:00 uur Eastern Standard Time (0 18 * * Mon,Wed,Fri) omgezet naar UTC.

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

Als u een cron-expressie converteert naar UTC, moet u mogelijk de dagen van de week in uw expressie wijzigen. In het volgende voorbeeld wordt Copilot gevraagd om een UTC cron-schema te maken voor bouwen van maandag tot en met vrijdag om 12:30 uur Centraal-Europese standaardtijd. Central European Standard Time loopt voor op UTC, dus de resulterende uitdrukking begint laat op zondagavond in plaats van vroeg op maandagochtend en eindigt op donderdag.

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

Als u meer informatie wilt over de cron-expressie die door Copilot wordt gegenereerd, kunt u Copilot vragen om een uitleg te geven van de gegenereerde cron-expressie in uw prompt.

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 wordt mogelijk gemaakt door AI, dus verrassingen en fouten zijn mogelijk. Zie voor meer informatie Algemene gebruik veelgestelde vragen over copilot.

klassieke

Klassieke planningen worden gedefinieerd met behulp van een grafische editor in plaats van cron-syntaxis. Zie Voorbeeldenvoor meer informatie over het definiëren van klassieke planningen.

Bekijk geplande runs

YAML

U kunt een voorbeeld van geplande builds bekijken door Geplande uitvoeringen te kiezen in het contextmenu op de pagina met details van pijplijn voor uw pijplijn.

Belangrijk

In het overzicht van geplande uitvoeringen worden alleen pijplijnen weergegeven die binnen zeven dagen na de huidige datum zijn gepland. Als uw cron-planning een interval heeft dat langer is dan 7 dagen en de volgende uitvoering is gepland om pas na zeven dagen vanaf de huidige datum te beginnen, wordt deze niet weergegeven in de weergave Geplande uitvoeringen.

Nadat u uw geplande triggers hebt gemaakt of bijgewerkt, kunt u deze controleren met behulp van geplande uitvoeringen weergave.

In dit voorbeeld worden de geplande runs weergegeven voor het volgende schema.

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

In het Geplande uitvoeringen venster worden de tijden weergegeven die zijn geconverteerd naar de lokale tijdzone die op de computer is ingesteld en wordt gebruikt om naar de Azure DevOps-portal te bladeren. In dit voorbeeld wordt een schermopname weergegeven die is gemaakt in de EST-tijdzone.

Notitie

Als u het schema voor een actieve pijplijn bijwerkt, wordt de geplande uitvoeringen weergave pas bijgewerkt met de nieuwe planning als de huidige actieve pijplijn is voltooid.

Klassieke

U kunt een voorbeeld van geplande builds bekijken door Geplande uitvoeringen te kiezen in het contextmenu op de pagina met details van pijplijn voor uw pijplijn.

Nadat u uw geplande triggers hebt gemaakt of bijgewerkt, kunt u deze controleren met behulp van deze weergave.

Het wordt uitgevoerd, zelfs als er geen codewijzigingen zijn

Standaard wordt uw pijplijn niet uitgevoerd zoals gepland als er sinds de laatste geslaagde geplande uitvoering geen codewijzigingen zijn aangebracht. Denk er bijvoorbeeld aan dat u elke nacht om 19:00 uur een pijplijn hebt gepland. Tijdens de weekdagen pusht u verschillende wijzigingen in uw code. De pijpleiding verloopt volgens schema. Tijdens het weekend hoeft u geen wijzigingen aan te brengen in uw code. Als er geen codewijzigingen zijn aangebracht sinds de geplande uitvoering op vrijdag, wordt de pijplijn niet uitgevoerd zoals gepland in het weekend.

YAML

Als u wilt afdwingen dat een pijplijn wordt uitgevoerd, zelfs wanneer er geen codewijzigingen zijn, kunt u het trefwoord always gebruiken.

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

klassieke

Als u de geplande pijplijn wilt configureren om alleen uit te voeren als er sinds de laatste build een wijziging is aangebracht, vink dan Alleen builds plannen als de bron of pijplijn is gewijzigdaan.

Limieten voor het aantal geplande uitvoeringen in YAML-pijplijnen

Er gelden bepaalde limieten voor hoe vaak u een pijplijn kunt plannen om uit te voeren. Deze limieten zijn ingesteld om misbruik van Azure Pipelines-resources te voorkomen, met name de door Microsoft gehoste agents. De limieten zijn:

• ongeveer 1000 keer per pijplijn per week
• 10 verwerkingen per pijplijn per 15 minuten

Migreren vanuit de klassieke editor

In de volgende voorbeelden ziet u hoe u uw planningen migreert van de klassieke editor naar YAML.

• Voorbeeld: Nightly build van Git-repo in meerdere tijdzones
• voorbeeld: Nachtbouw met verschillende frequenties

Voorbeeld: Nachtelijke build van Git-repo in meerdere tijdzones

In dit voorbeeld bevat de geplande trigger van de klassieke editor twee vermeldingen, waardoor de volgende builds worden geproduceerd.

• Elke maandag - vrijdag om 3:00 uur (UTC + 5:30 tijdzone), vertakkingen bouwen die voldoen aan de features/india/* vertakkingsfiltercriteria

  

• Elke maandag tot en met vrijdag om 3:00 uur (UTC - 5:00 tijd-zone), stel branches samen die voldoen aan de features/nc/* filtercriteria.

  

De equivalent in YAML geplande trigger is:

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/*

In het eerste schema, M-F 03:00 (UTC + 5:30) India dagelijkse build, is de cron-syntaxis (mm HH DD MM DW) 30 21 * * Sun-Thu.

• Minutes and Hours - 30 21 - Dit komt overeen met 21:30 UTC (9:30 PM UTC). Omdat de opgegeven tijdzone in de klassieke editor is UTC + 5:30, moeten we 5 uur en 30 minuten aftrekken van de gewenste buildtijd van 3:00 uur om op de gewenste UTC-tijd te komen om op te geven voor de YAML-trigger. U kunt AI-hulp krijgen van GitHub Copilot om uw cron-expressie te maken.
• Dagen en maanden worden opgegeven als jokertekens, omdat in dit schema niet wordt opgegeven dat deze alleen worden uitgevoerd op bepaalde dagen van de maand of op een specifieke maand.
• Dagen van de week - Sun-Thu - vanwege de tijdzoneconversie, zodat onze builds om 3:00 uur in de UTC + 5:30 India-tijdzone worden uitgevoerd, moeten we opgeven dat ze de vorige dag in UTC-tijd worden gestart. We kunnen ook de dagen van de week opgeven als 0-4 of 0,1,2,3,4.

In het tweede tijdschema, M-F 3:00 uur (UTC - 5) NC dagelijkse build, is de cron-syntaxis 0 8 * * Mon-Fri.

• Minutes and Hours - 0 8 - Dit komt overeen met 8:00 AM UTC. Omdat de opgegeven tijdzone in de klassieke editor is UTC - 5:00, moeten we 5 uur vanaf de gewenste buildtijd van 3:00 uur toevoegen om op de gewenste UTC-tijd te komen om op te geven voor de YAML-trigger. U kunt AI-hulp krijgen van GitHub Copilot om uw cron-expressie te maken.
• Dagen en maanden worden opgegeven als jokertekens, omdat in dit schema niet wordt opgegeven dat deze alleen worden uitgevoerd op bepaalde dagen van de maand of op een specifieke maand.
• Dagen van de week - Mon-Fri - omdat onze tijdzoneconversies niet meerdere dagen van de week omvatten voor onze gewenste planning, hoeven we hier geen conversie uit te voeren. We kunnen ook de dagen van de week opgeven als 1-5 of 1,2,3,4,5.

Belangrijk

De UTC-tijdzones in geplande YAML-triggers houden geen rekening met zomertijd.

Tip

Wanneer u 3-letter afkortingen voor de dagen van de week gebruikt en een periode van meerdere dagen tot en met zondag wilt gaan, moet Zon worden beschouwd als de eerste dag van de week, bijvoorbeeld voor een schema van middernacht EST, donderdag tot zondag, is de cron-syntaxis 0 5 * * Sun,Thu-Sat.

Voorbeeld: Nachtbouw met verschillende frequenties

In dit voorbeeld bevat de geplande trigger van de klassieke editor twee vermeldingen, waardoor de volgende builds worden geproduceerd.

• Elke maandag tot en met vrijdag om 3:00 uur 's ochtends UTC bouwen vertakkingen die voldoen aan de main- en de releases/*-vertakkingsfiltercriteria

  

• Elke zondag om 3:00 uur UTC bouwt u de releases/lastversion vertakking, zelfs als de bron of pijplijn niet is gewijzigd

  

De equivalente YAML-geplande trigger is:

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

In het eerste schema, M-V 03:00 (UTC) dagelijkse build, is de cron syntaxis 0 3 * * Mon-Fri.

• Minuten en Uren - 0 3 - Komt overeen met 3:00 AM UTC. Omdat de opgegeven tijdzone in de klassieke editor is UTC-, hoeven we geen tijdzoneconversies uit te voeren.
• Dagen en maanden worden opgegeven als jokertekens, omdat in dit schema niet wordt opgegeven dat deze alleen worden uitgevoerd op bepaalde dagen van de maand of op een specifieke maand.
• Dagen van de week - Mon-Fri - omdat er geen tijdzoneconversie is, komen de dagen van de week rechtstreeks overeen met het klassieke editorschema. We kunnen ook de dagen van de week opgeven als 1,2,3,4,5.

In het tweede schema, , wordt iedere zondag om 3:00 uur (UTC) de nieuwste buildversiegemaakt, en de cron-syntaxis is 0 3 * * Sun.

• Minutes and Hours - 0 3 - Dit komt overeen met 3:00 AM UTC. Omdat de opgegeven tijdzone in de klassieke editor is UTC-, hoeven we geen tijdzoneconversies uit te voeren.
• Dagen en maanden worden opgegeven als jokertekens, omdat in dit schema niet wordt opgegeven dat deze alleen worden uitgevoerd op bepaalde dagen van de maand of op een specifieke maand.
• Dagen van de week - Sun - omdat onze tijdzoneconversies niet meerdere dagen van de week omvatten voor onze gewenste planning, hoeven we hier geen conversie uit te voeren. We kunnen ook de dagen van de week opgeven als 0.
• We geven ook always: true op omdat deze build is gepland om uit te voeren of de broncode al dan niet is bijgewerkt.

FAQ

• Ik wil dat mijn pijplijn alleen volgens het schema draait en niet wanneer iemand een wijziging naar een branch pusht
• Ik heb een schema gedefinieerd in het YAML-bestand. Maar het werkte niet. Wat is er gebeurd?
• Mijn YAML-planningen werken prima. Maar ze werkten nu niet meer. Hoe kan ik fouten opsporen?
• Mijn code is niet gewijzigd, maar er wordt een geplande build geactiveerd. Waarom?
• Ik zie de geplande uitvoering in het deelvenster Geplande uitvoeringen. Op dat moment wordt het echter niet uitgevoerd. Waarom?
• Schema's die zijn gedefinieerd in een YAML-pijplijn werken voor de ene branch maar niet voor de andere. Hoe kan ik dit oplossen?

Ik wil dat mijn pijplijn alleen volgens het schema wordt uitgevoerd en niet wanneer iemand een wijziging naar een vertakking pusht

Als u wilt dat uw pijplijn alleen volgens het schema wordt uitgevoerd en niet wanneer iemand een wijziging naar een branch pusht of een wijziging naar de hoofdbranch samenvoegt, moet u de standaard CI- en PR-triggers expliciet uitschakelen in de pijplijn.

Als u de standaard-CI- en PULL-triggers wilt uitschakelen, voegt u de volgende instructies toe aan uw YAML-pijplijn en controleren of u de YAML-pijplijntriggers niet hebt overschreven met UI-triggers.

trigger: none
pr: none

Zie pr-definitie en triggerdefinitievoor meer informatie.

Ik heb een schema gedefinieerd in het YAML-bestand. Maar het werkte niet. Wat is er gebeurd?

• Controleer de eerstvolgende uitvoeringen die Azure Pipelines voor uw pijplijn heeft gepland. U kunt deze uitvoeringen vinden door in uw pijplijn de actie Geplande uitvoeringen te selecteren. De lijst wordt gefilterd om alleen de komende paar uitvoeringen in de komende dagen weer te geven. Als dit niet aan uw verwachtingen voldoet, is het waarschijnlijk het geval dat u uw cron-schema verkeerd hebt getypt of dat u het schema niet hebt gedefinieerd in de juiste vertakking. Lees het bovenstaande onderwerp voor meer informatie over het configureren van planningen. Evalueer de cron-syntaxis opnieuw. Alle tijden voor cron-schema's bevinden zich in UTC.

• Breng een kleine kleine kleine wijziging aan in uw YAML-bestand en push die update naar uw opslagplaats. Als er een probleem is opgetreden bij het lezen van de planningen uit het YAML-bestand eerder, moet dit nu worden opgelost.

• Als u planningen hebt gedefinieerd in de gebruikersinterface, worden uw YAML-schema's niet gehonoreerd. Zorg ervoor dat u geen UI-planningen hebt door naar de editor voor uw pijplijn te navigeren en vervolgens Triggerste selecteren.

• Er is een limiet voor het aantal runs dat u voor een specifieke pijplijn kunt plannen. Lees meer over limieten.

• Als er geen wijzigingen in uw code zijn, worden er mogelijk geen nieuwe uitvoeringen gestart in Azure Pipelines. Lees hoe u dit gedrag overschrijft.

Mijn YAML-planningen werken prima. Maar ze werkten nu niet meer. Hoe kan ik fouten opsporen?

• Als u always:trueniet hebt opgegeven, wordt uw pijplijn niet gepland, tenzij er updates zijn aangebracht in uw code. Controleer of er codewijzigingen zijn aangebracht en hoe u de planningen geconfigureerd.

• Er is een limiet voor het aantal keren dat u uw pijplijn kunt plannen. Controleer of u deze limieten hebt overschreden.

• Controleer of iemand meer planningen heeft ingeschakeld in de gebruikersinterface. Open de editor voor uw pijplijn en selecteer Triggers. Als ze planningen hebben gedefinieerd in de gebruikersinterface, worden uw YAML-schema's niet gehonoreerd.

• Controleer of uw pijplijn is onderbroken of uitgeschakeld. Selecteer Instellingen voor uw pijplijn.

• Bekijk de volgende runs die door Azure Pipelines zijn gepland voor uw pijplijn. U kunt deze uitvoeringen vinden door in uw pijplijn de actie Geplande uitvoeringen te selecteren. Als u de verwachte planningen niet ziet, moet u een kleine kleine kleine wijziging aanbrengen in uw YAML-bestand en de update naar uw opslagplaats pushen. Hiermee moeten de planningen opnieuw worden gesynchroniseerd.

• Als u GitHub gebruikt voor het opslaan van uw code, is het mogelijk dat Azure Pipelines mogelijk zijn beperkt door GitHub wanneer wordt geprobeerd een nieuwe uitvoering te starten. Controleer of u een nieuw proces handmatig kunt starten.

Mijn code is niet gewijzigd, maar er wordt een geplande build geactiveerd. Waarom?

• Mogelijk hebt u een optie ingeschakeld om altijd een geplande build uit te voeren, zelfs als er geen codewijzigingen zijn. Als u een YAML-bestand gebruikt, controleert u de syntaxis voor het schema in het YAML-bestand. Als u klassieke pijplijnen gebruikt, controleert u of u deze optie hebt aangevinkt in de geplande triggers.

• Mogelijk hebt u de pijplijn of een eigenschap van de pijplijn bijgewerkt. Hierdoor wordt een nieuwe uitvoering gepland, zelfs als u de broncode niet hebt bijgewerkt. Controleer de Geschiedenis van wijzigingen in de pijplijn met behulp van de klassieke editor.

• Mogelijk hebt u de serviceverbinding bijgewerkt die wordt gebruikt om verbinding te maken met de opslagplaats. Hierdoor wordt een nieuwe uitvoering gepland, zelfs als u de broncode niet hebt bijgewerkt.

• Azure Pipelines controleert eerst of er updates voor uw code zijn. Als Azure Pipelines uw opslagplaats niet kan bereiken of deze informatie kan ophalen, wordt er een informatieve rungemaakt. Het is een dummy-build om u te laten weten dat Azure Pipelines uw opslagplaats niet kan bereiken.

• Uw pijplijn heeft mogelijk geen volledig geslaagde build. Om te bepalen of u een nieuwe build wilt plannen of niet, zoekt Azure DevOps de laatste volledig geslaagde geplande build op. Als deze niet wordt gevonden, wordt er een nieuwe geplande build geactiveerd. Gedeeltelijk geslaagde geplande builds worden niet beschouwd als geslaagd, dus als uw pijplijn slechts gedeeltelijk geslaagde builds heeft, activeert Azure DevOps geplande builds, zelfs als uw code niet is gewijzigd.

Ik zie de geplande uitvoering in het deelvenster Geplande uitvoeringen. Op dat tijdstip wordt het echter niet uitgevoerd. Waarom?

• Het deelvenster Geplande runs toont alle mogelijke planningen. Het kan echter niet daadwerkelijk worden uitgevoerd, tenzij u echte updates voor de code hebt aangebracht. Als u wilt afdwingen dat een schema altijd wordt uitgevoerd, moet u ervoor zorgen dat u de eigenschap altijd in de YAML-pijplijn hebt ingesteld of dat u de optie hebt ingeschakeld om altijd in een klassieke pijplijn uit te voeren.

Schema's die zijn gedefinieerd in een YAML-pijplijn werken voor één branch, maar niet voor een andere. Hoe kan ik dit oplossen?

Planningen worden gedefinieerd in YAML-bestanden en deze bestanden zijn gekoppeld aan vertakkingen. Als u wilt dat een pijplijn gepland wordt voor een bepaalde tak, bijvoorbeeld features/X, moet u ervoor zorgen dat het YAML-bestand in die tak het cron-schema gedefinieerd heeft en dat het de juiste takken invoegt in het schema. Het YAML-bestand in de features/X vertakking moet de volgende schedule in dit voorbeeld hebben:

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

Zie Vertakkingsoverwegingen voor geplande triggersvoor meer informatie.