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 op basis van een planning, zoals een nachtbuild. Dit artikel bevat richtlijnen voor het gebruik van geplande triggers om uw pijplijnen uit te voeren op basis van een planning.
• Triggers op basis van gebeurtenissen starten uw pijplijn als reactie op gebeurtenissen, zoals het maken van een pull-aanvraag of het pushen naar een vertakking. Zie Triggers in Azure Pipelines voor 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 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 Triggers in Azure Pipelines voor meer informatie over het uitschakelen van standaardtriggers en navigeer naar de sectie waarin het type opslagplaats wordt beschreven.

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-pipeline 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 wilt uitvoeren in uw YAML-pipeline, moet u de geplande triggers verwijderen die zijn gedefinieerd in de gebruikersinterface van de pipelineinstellingen. Zodra alle geplande triggers voor de gebruikersinterface zijn verwijderd, moet er een push worden uitgevoerd om de YAML-geplande triggers te laten evalueren.

Als u geplande UI-triggers uit een YAML-pijplijn wilt verwijderen, raadpleegt u UI-instellingen voor het overschrijven van geplande YAML-triggers.

Geplande triggers configureren een pijplijn voor uitvoering volgens een schema dat is gedefinieerd met behulp van 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.
• Als u een exclude component opgeeft zonder een include component voor branches, is deze gelijk aan het opgeven * 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 voor vertakkingen voor geplande triggers

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

• Er wordt een pijplijn gemaakt.
• Het YAML-bestand van een pijplijn wordt bijgewerkt vanaf een push of 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 vertakking 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 uitvoeringen voor een vertakking worden alleen toegevoegd als de vertakking overeenkomt met de vertakkingsfilters voor de geplande triggers in het YAML-bestand in die specifieke vertakking.

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

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

Vervolgens wordt een nieuwe vertakking gemaakt op basis van main, benoemd 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 deze wijziging 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 het 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 mainbasis van en 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, wordt de release vertakking niet gebaseerd op die planning. 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.

Batchoverwegingen voor geplande triggers

De batch eigenschap configureert of de pijplijn moet worden uitgevoerd als de eerder geplande uitvoering wordt uitgevoerd; de standaardwaarde is false. Dit is ongeacht de versie van de pijplijnopslagplaats.

In de volgende tabel wordt beschreven hoe always en batch interactie.

Altijd	Batch	Gedrag
false	false	Pijplijn wordt alleen uitgevoerd als er een wijziging is met betrekking tot de laatste geslaagde geplande pijplijnuitvoering.
false	true	Pijplijn wordt alleen uitgevoerd als er een wijziging is met betrekking tot de laatste geslaagde geplande pijplijnuitvoering en er geen geplande pijplijnuitvoering wordt uitgevoerd.
true	false	Pijplijnuitvoeringen volgens het cron-schema.
true	true	Pijplijnuitvoeringen volgens het cron-schema.

Belangrijk

Wanneer always istrue, wordt de pijplijn uitgevoerd volgens het cron-schema, zelfs wanneerbatch.true

Variabele Build.CronSchedule.DisplayName

Wanneer een pijplijn wordt uitgevoerd vanwege een geplande cron-trigger, bevat de vooraf gedefinieerde Build.CronSchedule.DisplayName variabele het displayName 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 Build.CronSchedule.DisplayName variabele 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-voorbeelden voor meer voorbeelden.

Klassiek

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

Als uw opslagplaats Git, GitHub of Andere Git voor Azure-opslagplaatsen 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

De eerste planning, 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/*.

Met de tweede planning, wekelijkse zondagse build, wordt op zondagmiddag een pijplijn uitgevoerd, ongeacht of de code is gewijzigd of niet sinds de laatste uitvoering, voor alle releases/* vertakkingen.

Notitie

De tijdzone voor cron-planningen is UTC, dus in deze voorbeelden zijn de middernacht-build en de middag-build om middernacht en middag in UTC.

Zie Migreren vanuit de klassieke editor voor meer voorbeelden.

Klassiek

Voorbeeld: Nightly build van Git-opslagplaats in meerdere tijdzones

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

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

  

• Elke maandag - vrijdag om 3:00 uur (UTC - 5:00 tijdzone), vertakkingen bouwen die voldoen aan de features/nc/* filtercriteria voor vertakkingen

  

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 - vrijdag om 3:00 uur UTC bouwen vertakkingen die voldoen aan de main criteria en releases/* vertakkingsfilters

  

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

  

Cron-syntaxis

YAML

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
Minuten	0 tot en met 59
Tijden	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.

Format	Voorbeeld	Beschrijving
Jokerteken	*	Komt overeen met alle waarden voor dit veld
Enkele 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

Opmerking	Cron-expressie
Bouw elke maandag, woensdag en vrijdag om 18:00 uur	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5 of 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-expressie voor meer informatie over ondersteunde indelingen.

Klassiek

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

Weergave geplande uitvoeringen

YAML

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

Belangrijk

In de weergave geplande uitvoeringen worden alleen pijplijnen weergegeven die binnen zeven dagen vanaf 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 na zeven dagen vanaf de huidige datum te beginnen, wordt deze niet weergegeven in de weergave Geplande uitvoeringen .

Nadat u de geplande triggers hebt gemaakt of bijgewerkt, kunt u deze controleren met de weergave Geplande uitvoeringen .

In dit voorbeeld worden de geplande uitvoeringen voor de volgende planning weergegeven.

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

In de vensters geplande uitvoeringen worden de tijden weergegeven die zijn geconverteerd naar de lokale tijdzone die is ingesteld op de computer die 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 weergave Geplande uitvoeringen pas bijgewerkt met de nieuwe planning als de huidige pijplijn is voltooid.

Klassiek

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

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

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 pijplijn wordt volgens schema uitgevoerd. 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 always trefwoord gebruiken.

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

Klassiek

Als u de geplande pijplijn alleen wilt configureren om te bouwen als er sinds de laatste build een wijziging is aangebracht, controleert u alleen planningsbuilds als de bron of pijplijn is gewijzigd.

Limieten voor het aantal geplande uitvoeringen in YAML-pijplijnen

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

• ongeveer 1000 uitvoeringen per pijplijn per week
• 10 uitvoeringen 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-opslagplaats in meerdere tijdzones
• Voorbeeld: Nachtbouw met verschillende frequenties

Voorbeeld: Nightly build van Git-opslagplaats 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/* filtercriteria voor vertakkingen

  

• Elke maandag - vrijdag om 3:00 uur (UTC - 5:00 tijdzone), vertakkingen bouwen die voldoen aan de features/nc/* filtercriteria voor vertakkingen

  

De equivalente 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 3:00 am (UTC + 5:30) India dagelijkse build, de cron syntaxis (mm HH DD MM DW) is 30 21 * * Sun-Thu.

• Minutes and Hours - 30 21 Dit wordt toegewezen aan 21:30 UTC (9:30 PM UTC). Omdat de opgegeven tijdzone in de klassieke editor UTC + 5:30 is, 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.
• 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 worden uitgevoerd om 3:00 uur in de UTC + 5:30 India-tijdzone, 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 schema, M-F 3:00 AM (UTC - 5) NC dagelijkse build, is 0 8 * * Mon-Fride cron syntaxis .

• Minutes and Hours - 0 8 Dit wordt toegewezen aan 8:00 AM UTC. Omdat de opgegeven tijdzone in de klassieke editor UTC - 5:00 is, 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.
• 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 letterdagen van de week gebruikt en een periode van meerdere dagen door de zon wilt, moet de zon worden beschouwd als de eerste dag van de week, bijvoorbeeld voor een schema van middernacht EST, donderdag tot zondag, de cron-syntaxis is 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 - vrijdag om 3:00 uur UTC bouwen vertakkingen die voldoen aan de main criteria en releases/* vertakkingsfilters

  

• 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 is de dagelijkse build van M-F 3:00 (UTC) de cron-syntaxis 0 3 * * Mon-Fri.

• Minutes and Hours - 0 3 Dit wordt toegewezen aan 3:00 AM UTC. Omdat de opgegeven tijdzone in de klassieke editor UTC is, 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, de dagen van de weekkaart rechtstreeks vanuit het klassieke editorschema. We kunnen ook de dagen van de week opgeven als 1,2,3,4,5.

In het tweede schema, zondag 3:00 uur (UTC) wekelijkse nieuwste versie build, is 0 3 * * Sunde cron syntaxis.

• Minutes and Hours - 0 3 Dit wordt toegewezen aan 3:00 AM UTC. Omdat de opgegeven tijdzone in de klassieke editor UTC is, 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 op always: true omdat deze build is gepland om uit te voeren of de broncode al dan niet is bijgewerkt.

Veelgestelde vragen

• Ik wil dat mijn pijplijn alleen volgens het schema wordt uitgevoerd en niet wanneer iemand een wijziging naar een vertakking pusht
• Ik heb een schema gedefinieerd in het YAML-bestand. Maar het liep 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 YAML-pijplijnwerk voor één vertakking, 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 vertakking pusht of een wijziging in de hoofdbranch samenvoegt, moet u de standaard-CI- en PULL-triggers voor de pijplijn expliciet uitschakelen.

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

trigger: none
pr: none

Zie pr-definitie en triggerdefinitie voor meer informatie.

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

• Controleer de volgende uitvoeringen die door Azure Pipelines zijn gepland voor uw pijplijn. U kunt deze uitvoeringen vinden door de actie Geplande uitvoeringen in uw pijplijn 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 Triggers te selecteren.

• Er is een limiet voor het aantal uitvoeringen dat u voor een 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. Meer informatie over het overschrijven van dit gedrag.

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

• Als u dit niet hebt opgegeven always:true, wordt uw pijplijn niet gepland, tenzij er updates zijn aangebracht in uw code. Controleer of er codewijzigingen zijn aangebracht en hoe u de planningen hebt 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.

• Controleer de volgende uitvoeringen die door Azure Pipelines zijn gepland voor uw pijplijn. U kunt deze uitvoeringen vinden door de actie Geplande uitvoeringen in uw pijplijn 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 nieuwe uitvoering 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 gecontroleerd in de geplande triggers.

• Mogelijk hebt u de build-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 uitvoering gemaakt. 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 moment wordt het echter niet uitgevoerd. Waarom?

• In het deelvenster Geplande uitvoeringen worden alle mogelijke planningen weergegeven. 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 altijd eigenschap in de YAML-pijplijn hebt ingesteld of de optie hebt ingeschakeld om altijd in een klassieke pijplijn uit te voeren.

Schema's die zijn gedefinieerd in YAML-pijplijnwerk voor één vertakking, maar niet voor de 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 voor een bepaalde vertakking wordt gepland, moet features/Xu ervoor zorgen dat het YAML-bestand in die vertakking het cron-schema heeft gedefinieerd en dat het de juiste vertakkingsopnamen voor het schema heeft. Het YAML-bestand in de features/X vertakking moet het volgende schedule hebben in dit voorbeeld:

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

Zie Vertakkingsoverwegingen voor geplande triggers voor meer informatie.