Konfigurieren von Zeitplänen für Pipelines

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

Azure Pipelines bietet mehrere Arten von Triggern, mit denen Sie konfigurieren können, wie Ihre Pipeline gestartet wird.

• Plantrigger starten Ihre Pipeline basierend auf einem Zeitplan, z. B. als nächtlichen Build. Dieser Artikel enthält Anleitungen dazu, wie Sie Plantrigger zum Ausführen Ihrer Pipelines basierend auf einem Zeitplan verwenden.
• Ereignisbasierte Trigger starten Ihre Pipeline als Reaktion auf Ereignisse, z. B. das Erstellen eines Pull Requests oder das Pushen an einen Branch. Informationen zur Verwendung ereignisbasierter Trigger finden Sie unter Trigger in Azure Pipelines.

Sie können Plantrigger und ereignisbasierte Trigger in Ihren Pipelines kombinieren, um z. B. den Build jedes Mal zu überprüfen, wenn ein Push durchgeführt wird (CI-Trigger), wenn ein Pull Request durchgeführt wird (PR-Trigger) und wenn ein nächtlicher Build ausgeführt wird (Plantrigger). Wenn Sie Ihre Pipeline nur basierend auf einem Zeitplan erstellen möchten, nicht als Reaktion auf ereignisbasierte Trigger, stellen Sie sicher, dass in Ihrer Pipeline keine anderen Trigger aktiviert sind. Beispielsweise enthalten YAML-Pipelines in einem GitHub-Repository CI-Trigger und PR-Trigger, die standardmäßig aktiviert sind. Informationen zum Deaktivieren von Standardtriggern finden Sie unter Trigger in Azure Pipelines. Navigieren Sie dort zu dem Abschnitt für Ihren Repositorytyp.

Geplante Trigger

YAML

Wichtig

Plantrigger, die über die Benutzeroberfläche für Pipelineeinstellungen definiert werden, haben Vorrang vor YAML-Plantriggern.

Wenn Ihre YAML-Pipeline sowohl über geplante YAML-Trigger als auch über in der Benutzeroberfläche definierte geplante Trigger verfügt, werden nur die in der Benutzeroberfläche definierten geplanten Trigger ausgeführt. Um die von YAML definierten geplanten Trigger in Ihrer YAML-Pipeline auszuführen, müssen Sie die geplanten Trigger entfernen, die in der Benutzeroberfläche für die Pipelineeinstellungen definiert sind. Nachdem alle auf der Benutzerfläche definierten Plantrigger entfernt wurden, muss ein Push erfolgen, damit die zu startenden YAML-Plantrigger überprüft werden können.

Informationen zum Löschen von auf der Benutzeroberfläche definierten Plantriggern aus einer YAML-Pipeline finden Sie unter Überschreiben von YAML-Plantriggern durch Benutzeroberflächeneinstellungen.

Plantrigger konfigurieren eine Pipeline für die Ausführung nach einem Zeitplan, der mithilfe der Cron-Syntax definiert ist.

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

Für geplante Pipelines in YAML gelten die folgenden Einschränkungen.

• Die Zeitzone für Cron-Zeitpläne ist UTC.
• Wenn Sie eine exclude-Klausel ohne include-Klausel für branches angeben, ist dies gleichbedeutend mit der Angabe von * in der include-Klausel.
• Sie können keine Pipelinevariablen verwenden, wenn Sie Zeitpläne angeben.
• Wenn Sie Vorlagen in Ihrer YAML-Datei verwenden, müssen die Zeitpläne in der YAML-Hauptdatei angegeben werden, nicht in den Vorlagendateien.

Überlegungen zu Branches für Plantrigger

Plantrigger werden für einen Branch ausgewertet, wenn die folgenden Ereignisse auftreten.

• Eine Pipeline wird erstellt.
• Die YAML-Datei einer Pipeline wird entweder durch einen Push oder durch Bearbeitung im Pipeline-Editor aktualisiert.
• Der YAML-Dateipfad einer Pipeline wird aktualisiert und verweist auf eine andere YAML-Datei. Diese Änderung aktualisiert nur den Standardbranch und nimmt daher nur Zeitpläne in der aktualisierten YAML-Datei für den Standardbranch auf. Wenn andere Branches den Standardbranch anschließend mergen, z. B. mit git pull origin main, werden die Plantrigger aus der neu referenzierten YAML-Datei für diesen Branch ausgewertet.
• Ein neuer Branch wird erstellt.

Nachdem eines dieser Ereignisse in einem Branch aufgetreten ist, werden alle geplanten Ausführungen für diesen Branch hinzugefügt, sofern dieser Branch den Branchfiltern für die Plantrigger entspricht, die in der YAML-Datei in diesem Branch enthalten sind.

Wichtig

Geplante Ausführungen für einen Branch werden nur hinzugefügt, wenn der Branch den Branchfiltern für die Plantrigger in der YAML-Datei in diesem bestimmten Branch entspricht.

Beispielsweise wird eine Pipeline mit dem folgenden Zeitplan erstellt, und diese Version der YAML-Datei wird in den main-Branch eingecheckt. Dieser Zeitplan erstellt den main-Branch täglich.

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

Als Nächstes wird ein neuer Branch basierend auf main erstellt und als new-feature bezeichnet. Die Plantrigger aus der YAML-Datei im neuen Branch werden gelesen, und da es keine Übereinstimmung für den new-feature-Branch gibt, werden keine Änderungen an den geplanten Builds vorgenommen, und der new-feature-Branch wird nicht mit einem Plantrigger erstellt.

Wenn new-feature zur Liste branches hinzugefügt und diese Änderung an den new-feature-Branch gepusht wird, wird die YAML-Datei gelesen, und da new-feature sich jetzt in der Liste der Branches befindet, wird ein geplanter Build für den new-feature-Branch hinzugefügt.

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

Beachten Sie jetzt, dass ein Branch namens release basierend auf main erstellt wird. Dann wird release den Branchfiltern in der YAML-Datei im main-Branch hinzugefügt, nicht aber im neu erstellten release-Branch.

# 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

Da release den Branchfiltern im main-Branch hinzugefügt wurde, aber nicht den Branchfiltern im release-Branch, wird der release-Branch nicht basierend auf diesem Zeitplan erstellt. Nur wenn der release-Branch den Branchfiltern in der YAML-Datei im Releasebranch hinzugefügt wird, wird der geplante Build dem Zeitplan hinzugefügt.

Überlegungen zu Batches für Plantrigger

Die batch-Eigenschaft konfiguriert, ob die Pipeline ausgeführt werden soll, wenn die zuvor geplante Ausführung ausgeführt wird. Der Standardwert ist false. Dies ist unabhängig von der Version des Pipelinerepositorys.

In der folgenden Tabelle wird beschrieben, wie always und batch interagieren.

Immer	Batch	Verhalten
false	false	Die Pipeline wird nur ausgeführt, wenn es eine Änderung in Bezug auf die letzte erfolgreiche geplante Pipelineausführung gibt.
false	true	Die Pipeline wird nur ausgeführt, wenn es eine Änderung in Bezug auf die letzte erfolgreiche geplante Pipelineausführung gibt und keine geplante Pipelineausführung ausgeführt wird.
true	false	Die Pipeline wird gemäß dem Cron-Zeitplan ausgeführt.
true	true	Die Pipeline wird gemäß dem Cron-Zeitplan ausgeführt.

Wichtig

Wenn always gleich true ist, wird die Pipeline gemäß dem Cron-Zeitplan ausgeführt, auch wenn batch gleich true ist.

Build.CronSchedule.DisplayName-Variable

Wenn eine Pipeline aufgrund eines geplanten Cron-Triggers ausgeführt wird, enthält die vordefinierte Build.CronSchedule.DisplayName-Variable den displayName des Cron-Zeitplans, der die Pipelineausführung ausgelöst hat.

Ihre YAML-Pipeline kann mehrere Cron-Zeitpläne enthalten, und Sie möchten möglicherweise, dass Ihre Pipeline je nach ausgeführtem Cron-Zeitplan unterschiedliche Phasen oder Aufträge ausführt. Beispielsweise verfügen Sie über einen nächtlichen Build und einen wöchentlichen Build, und Sie möchten eine bestimmte Phase nur während des nächtlichen Builds ausführen. Sie können die Build.CronSchedule.DisplayName-Variable in einer Auftrags- oder Phasenbedingung verwenden, um zu bestimmen, ob dieser Auftrag oder diese Phase ausgeführt werden soll.

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

Weitere Beispiele finden Sie unter schedules.cron-Beispiele.

Klassisch

Wählen Sie im klassischen Editor die Tage und Uhrzeiten aus, zu denen Sie den Build ausführen möchten.

Wenn es sich bei Ihrem Repository um ein Azure Repos Git-, GitHub- oder anderweitiges Git-Repository handelt, können Sie auch Branches angeben, die ein- oder ausgeschlossen werden sollen. Wenn Sie Platzhalterzeichen verwenden möchten, geben Sie die Branchspezifikation (z. B. features/modules/*) ein, und drücken Sie dann die EINGABETASTE.

Beispiele

YAML

Das folgende Beispiel definiert zwei Zeitpläne:

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

Der erste Zeitplan, Daily midnight build, führt täglich um Mitternacht für den main-Branch und alle releases/*-Branches mit Ausnahme der Branches unter releases/ancient/* eine Pipeline aus, aber nur, wenn sich der Code seit der letzten erfolgreichen geplanten Ausführung geändert hat.

Der zweite Zeitplan, Weekly Sunday build, führt jeden Sonntag um 12:00 Uhr mittags eine Pipeline für alle releases/*-Branches aus, unabhängig davon, ob sich der Code seit der letzten Ausführung geändert hat.

Hinweis

Für Cron-Zeitpläne lautet die Zeitzone UTC, daher finden in diesen Beispielen der „midnight build“ um 0:00 Uhr und der „noon build“ um 12:00 Uhr in UTC statt.

Weitere Beispiele finden Sie unter Migrieren vom klassischen Editor.

Klassisch

Beispiel: nächtlicher Build eines Git-Repositorys in mehreren Zeitzonen

In diesem Beispiel enthält der Plantrigger im klassischen Editor zwei Einträge, die die folgenden Builds erzeugen.

• Jeden Tag von Montag bis Freitag sollen um 3:00 Uhr (Zeitzone „UTC +5:30“) Branches erstellt werden, die den Branchfilterkriterien features/india/* entsprechen.

  

• Jeden Tag von Montag bis Freitag sollen um 3:00 Uhr (Zeitzone „UTC -5:00“) Branches erstellt werden, die den Branchfilterkriterien features/nc/* entsprechen.

  

Beispiel: nächtlicher Build mit unterschiedlicher Häufigkeit

Azure Pipelines und Azure DevOps Server 2019

In diesem Beispiel enthält der Plantrigger im klassischen Editor zwei Einträge, die die folgenden Builds erzeugen.

• Jeden Tag von Montag bis Freitag sollen um 3:00 Uhr UTC Branches erstellt werden, die den Branchfilterkriterien main und releases/* entsprechen.

  

• Jeden Sonntag soll um 3:00 Uhr UTC der releases/lastversion-Branch erstellt werden, auch wenn die Quelle oder die Pipeline sich nicht geändert hat.

  

Cron-Syntax

YAML

Jeder Cron-Ausdruck für Plantrigger in Azure Pipelines ist ein durch Leerzeichen getrennter Ausdruck mit fünf Einträgen in der folgenden Reihenfolge. Der Ausdruck wird in einfache Anführungszeichen eingeschlossen: '.

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

Feld	Zulässige Werte
Minuten	0 bis 59
Stunden	0 bis 23
Tage	1 bis 31
Monate	1 bis 12, vollständige englische Namen, erste drei Buchstaben der englischen Namen
Wochentage	0 bis 6 (beginnend mit Sonntag), vollständige englische Namen, erste drei Buchstaben der englischen Namen

Werte können in den folgenden Formaten vorliegen.

Format	Beispiel	BESCHREIBUNG
Platzhalter	*	Entspricht allen Werten für dieses Feld.
Einzelwert	5	Gibt einen einzelnen Wert für dieses Feld an.
Komma-getrennt	3,5,6	Gibt mehrere Werte für dieses Feld an. Mehrere Formate können kombiniert werden, z. B. 1,3-6.
Bereiche	1-3	Der Wertebereich für dieses Feld.
Intervalle	*/4 oder 1-5/2	Intervalle, die diesem Feld entsprechen, z. B. jeder vierte Wert oder der Wertebereich 1–5 mit dem Schrittintervall 2.

Beispiel	Cron-Ausdruck
Jeden Montag, Mittwoch und Freitag um 18:00 Uhr erstellen	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5oder 0 18 * * 1-5/2
Alle 6 Stunden erstellen	0 0,6,12,18 * * *, 0 */6 * * * oder 0 0-18/6 * * *
Ab 9:00 Uhr alle 6 Stunden erstellen	0 9,15,21 * * * oder 0 9-21/6 * * *

Weitere Informationen zu unterstützten Formaten finden Sie unter Crontab Expression.

Klassisch

Klassische Zeitpläne werden nicht mithilfe der Cron-Syntax, sondern in einem grafischen Editor definiert. Informationen zum Definieren klassischer Zeitpläne finden Sie unter Beispiele.

Ansicht „Geplante Ausführungen“

YAML

Sie können eine Vorschau der bevorstehenden geplanten Builds anzeigen, indem Sie auf der Seite mit den Pipelinedetails für Ihre Pipeline im Kontextmenü die Option Geplante Ausführungen auswählen.

Wichtig

In der Ansicht „Geplante Ausführungen“ werden nur Pipelines angezeigt, deren Ausführung innerhalb von sieben Tagen nach dem aktuellen Datum geplant ist. Wenn Ihr Cron-Zeitplan ein Intervall von mehr als 7 Tagen aufweist und die nächste Ausführung später als sieben Tage nach dem aktuellen Datum gestartet werden soll, wird er nicht in der Ansicht Geplante Ausführungen angezeigt.

Nachdem Sie Ihre Plantrigger erstellt oder aktualisiert haben, können Sie diese mithilfe der Ansicht Geplante Ausführungen überprüfen.

Dieses Beispiel zeigt die geplanten Ausführungen für den folgenden Zeitplan an.

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

Die im Fenster Geplante Ausführungen angezeigten Zeiten wurden in die lokale Zeitzone konvertiert, die auf dem Computer festgelegt ist, auf dem zum Azure DevOps-Portal navigiert wird. Dieses Beispiel zeigt einen Screenshot in der Zeitzone „EST“.

Hinweis

Wenn Sie den Zeitplan für eine ausgeführte Pipeline aktualisieren, wird die Ansicht Geplante Ausführungen erst mit dem neuen Zeitplan aktualisiert, nachdem die aktuell ausgeführte Pipeline abgeschlossen ist.

Klassisch

Sie können eine Vorschau der bevorstehenden geplanten Builds anzeigen, indem Sie auf der Seite mit den Pipelinedetails für Ihre Pipeline im Kontextmenü die Option Geplante Ausführungen auswählen.

Nachdem Sie Ihre Plantrigger erstellt oder aktualisiert haben, können Sie diese mithilfe dieser Ansicht überprüfen.

Ausführen, auch wenn keine Codeänderungen vorhanden sind

Standardmäßig wird Ihre Pipeline nicht wie geplant ausgeführt, wenn seit der letzten erfolgreichen geplanten Ausführung keine Codeänderungen vorgenommen wurden. Stellen Sie sich beispielsweise eine Pipeline vor, deren Ausführung Sie jeden Abend um 21:00 Uhr geplant haben. Unter der Woche pushen Sie diverse Änderungen an Ihren Code. Die Pipeline wird gemäß Zeitplan ausgeführt. Am Wochenende nehmen Sie keine Änderungen an Ihrem Code vor. Wenn seit der geplanten Ausführung am Freitag keine Codeänderungen erfolgt sind, wird die Pipeline während des Wochenendes nicht wie geplant ausgeführt.

YAML

Um die Ausführung einer Pipeline zu erzwingen, auch wenn keine Codeänderungen vorhanden sind, können Sie das Schlüsselwort always verwenden.

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

Klassisch

Um die geplante Pipeline so zu konfigurieren, dass sie nur dann erstellt wird, wenn seit dem letzten Build eine Änderung aufgetreten ist, aktivieren Sie Erstellen Sie nur dann einen Zeitplan für Builds, wenn sich die Quelle oder die Pipeline geändert hat.

Grenzwerte für die Anzahl geplanter Ausführungen in YAML-Pipelines

Es gibt bestimmte Grenzwerte für die Häufigkeit der Ausführung einer Pipeline. Diese Grenzwerte wurden eingerichtet, um den Missbrauch von Azure Pipelines-Ressourcen, insbesondere der von Microsoft gehosteten Agents, zu verhindern. Die Limits sind:

• ca. 1.000 Ausführungen pro Pipeline pro Woche
• 10 Ausführungen pro Pipeline pro 15 Minuten

Migrieren vom klassischen Editor

Die folgenden Beispiele zeigen, wie Sie Ihre Zeitpläne vom klassischen Editor zu YAML migrieren.

• Beispiel: nächtlicher Build eines Git-Repositorys in mehreren Zeitzonen
• Beispiel: nächtlicher Build mit unterschiedlicher Häufigkeit

Beispiel: nächtlicher Build eines Git-Repositorys in mehreren Zeitzonen

In diesem Beispiel enthält der Plantrigger im klassischen Editor zwei Einträge, die die folgenden Builds erzeugen.

• Jeden Tag von Montag bis Freitag sollen um 3:00 Uhr (Zeitzone „UTC +5:30“) Branches erstellt werden, die den Branchfilterkriterien features/india/* entsprechen.

  

• Jeden Tag von Montag bis Freitag sollen um 3:00 Uhr (Zeitzone „UTC -5:00“) Branches erstellt werden, die den Branchfilterkriterien features/nc/* entsprechen.

  

Der entsprechende YAML-Plantrigger lautet:

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

Im ersten Zeitplan, M-F 3:00 AM (UTC + 5:30) India daily build, lautet die Cron-Syntax (mm HH DD MM DW) 30 21 * * Sun-Thu.

• Minuten und Stunden – 30 21: Dies entspricht 21:30 UTC (9:30 PM UTC). Da die angegebene Zeitzone im klassischen Editor UTC +5:30 ist, müssen wir 5 Stunden und 30 Minuten von der gewünschten Uhrzeit 3:00 Uhr subtrahieren, um zu der gewünschten UTC-Zeit zu gelangen, die wir für den YAML-Trigger angeben müssen.
• Für die Tage und Monate sind Platzhalterzeichen angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder in einem bestimmten Monat ausgeführt werden soll.
• Wochentage – Sun-Thu: Aufgrund der Zeitzonenkonvertierung müssen wir die Startzeit am vorangehenden Tag in UTC-Zeit angeben, damit unsere Builds um 3:00 Uhr in der Zeitzone „UTC +5:30 (Indien)“ ausgeführt werden. Wir können auch Wochentage im Format 0-4 oder 0,1,2,3,4 angeben.

Im zweiten Zeitplan, M-F 3:00 AM (UTC - 5) NC daily build, lautet die Cron-Syntax 0 8 * * Mon-Fri.

• Minuten und Stunden – 0 8: Dies entspricht 8:00 AM UTC. Da die angegebene Zeitzone im klassischen Editor UTC +5:00 ist, müssen wir 5 Stunden zur gewünschten Uhrzeit 3:00 Uhr addieren, um zu der gewünschten UTC-Zeit zu gelangen, die wir für den YAML-Trigger angeben müssen.
• Für die Tage und Monate sind Platzhalterzeichen angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder in einem bestimmten Monat ausgeführt werden soll.
• Wochentage – Mon-Fri: Da sich unsere Zeitzonenkonvertierungen nicht über mehrere Wochentage für den gewünschten Zeitplan erstrecken, müssen wir hier keine Konvertierung durchführen. Wir können auch Wochentage im Format 1-5 oder 1,2,3,4,5 angeben.

Wichtig

Bei den UTC-Zeitzonen in YAML-Plantriggern wird die Sommerzeit nicht berücksichtigt.

Tipp

Bei Verwendung von dreibuchstabigen Wochentagen und einer gewünschten Spanne von mehreren Tagen bis Sonntag sollte der Sonntag („Sun“) als erster Tag der Woche betrachtet werden. Für einen Zeitplan von Donnerstag bis Sonntag um Mitternacht EST lautet die Cronsyntax 0 5 * * Sun,Thu-Sat.

Beispiel: nächtlicher Build mit unterschiedlicher Häufigkeit

In diesem Beispiel enthält der Plantrigger im klassischen Editor zwei Einträge, die die folgenden Builds erzeugen.

• Jeden Tag von Montag bis Freitag sollen um 3:00 Uhr UTC Branches erstellt werden, die den Branchfilterkriterien main und releases/* entsprechen.

  

• Jeden Sonntag soll um 3:00 Uhr UTC der releases/lastversion-Branch erstellt werden, auch wenn die Quelle oder die Pipeline sich nicht geändert hat.

  

Der entsprechende YAML-Plantrigger lautet:

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

Im ersten Zeitplan, M-F 3:00 AM (UTC) daily build, lautet die Cron-Syntax 0 3 * * Mon-Fri.

• Minuten und Stunden – 0 3: Dies entspricht 3:00 AM UTC. Da die angegebene Zeitzone im klassischen Editor UTC ist, müssen keine Zeitzonenkonvertierungen ausgeführt werden.
• Für die Tage und Monate sind Platzhalterzeichen angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder in einem bestimmten Monat ausgeführt werden soll.
• Wochentage – Mon-Fri: Da keine Zeitzonenkonvertierung angewendet wird, entsprechen die Wochentage direkt dem Zeitplan im klassischen Editor. Wir können auch Wochentage im Format 1,2,3,4,5 angeben.

Im zweiten Zeitplan, Sunday 3:00 AM (UTC) weekly latest version build, lautet die Cron-Syntax 0 3 * * Sun.

• Minuten und Stunden – 0 3: Dies entspricht 3:00 AM UTC. Da die angegebene Zeitzone im klassischen Editor UTC ist, müssen keine Zeitzonenkonvertierungen ausgeführt werden.
• Für die Tage und Monate sind Platzhalterzeichen angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder in einem bestimmten Monat ausgeführt werden soll.
• Wochentage – Sun: Da sich unsere Zeitzonenkonvertierungen nicht über mehrere Wochentage für den gewünschten Zeitplan erstrecken, müssen wir hier keine Konvertierung durchführen. Wir können auch Wochentage im Format 0 angeben.
• Außerdem geben wir always: true an, da die Ausführung dieses Builds unabhängig davon geplant ist, ob der Quellcode aktualisiert wurde oder nicht.

Häufig gestellte Fragen

• Ich möchte, dass meine Pipeline nur nach dem Zeitplan ausgeführt wird und nicht, wenn jemand eine Änderung an einen Branch pusht.
• Ich habe einen Zeitplan in der YAML-Datei definiert. Aber er wurde nicht ausgeführt. Was ist passiert?
• Meine YAML-Zeitpläne haben gut funktioniert. Aber jetzt funktionieren sie nicht mehr. Wie kann ich das debuggen?
• Mein Code hat sich nicht geändert, aber dennoch wird ein geplanter Build ausgelöst. Warum?
• Die geplante Ausführung wird im Bereich „Geplante Ausführungen“ angezeigt. Aber die Ausführung erfolgt nicht zu diesem Zeitpunkt. Warum?
• In einer YAML-Pipeline definierte Zeitpläne funktionieren für einen Branch, aber nicht für den anderen. Wie kann ich dies korrigieren?

Ich möchte, dass meine Pipeline nur nach dem Zeitplan ausgeführt wird und nicht, wenn jemand eine Änderung an einen Branch pusht.

Wenn Ihre Pipeline nur nach dem Zeitplan ausgeführt werden soll, und nicht, wenn jemand eine Änderung an einen Branch pusht oder eine Änderung im Mainbranch zusammenführt, müssen Sie die CI- und PR-Standardtrigger in der Pipeline explizit deaktivieren.

Um die CI- und PR-Standardtrigger zu deaktivieren, fügen Sie der YAML-Pipeline die folgenden Anweisungen hinzu und stellen sicher, dass Sie die YAML-Pipelinetrigger nicht mit Benutzeroberflächentriggern außer Kraft gesetzt haben.

trigger: none
pr: none

Weitere Informationen finden Sie unter PR-Definition und Triggerdefinition.

Ich habe einen Zeitplan in der YAML-Datei definiert. Aber er wurde nicht ausgeführt. Was ist passiert?

• Überprüfen Sie die nächsten Ausführungen, die Azure Pipelines für Ihre Pipeline geplant hat. Sie finden diese Ausführungen, indem Sie die Aktion Geplante Ausführungen in Ihrer Pipeline auswählen. Die Liste wird gefiltert, sodass Ihnen nur die bevorstehenden Ausführungen in den nächsten Tagen angezeigt werden. Wenn dies nicht Ihren Erwartungen entspricht, haben Sie den Cron-Zeitplan wahrscheinlich falsch eingegeben oder den Zeitplan nicht im richtigen Branch definiert. Im Thema oben finden Sie genaue Informationen, die Ihnen helfen zu verstehen, wie Zeitpläne konfiguriert werden. Überprüfen Sie die Cron-Syntax. Alle Zeitangaben für Cron-Zeitpläne erfolgen in UTC.

• Nehmen Sie eine kleine unwichtige Änderung an Ihrer YAML-Datei vor, und pushen Sie dieses Update in Ihr Repository. Wenn es zuvor ein Problem beim Lesen der Zeitpläne aus der YAML-Datei gab, sollte dieses jetzt behoben sein.

• Wenn Zeitpläne vorhanden sind, die auf der Benutzeroberfläche definiert wurden, werden Ihre YAML-Zeitpläne nicht berücksichtigt. Stellen Sie sicher, dass keine auf der Benutzeroberfläche definierten Zeitpläne vorliegen, indem Sie zum Editor für Ihre Pipeline navigieren und dann Trigger auswählen.

• Die Anzahl von Ausführungen, die Sie für eine Pipeline planen können, ist begrenzt. Weitere Informationen finden Sie unter Grenzwerte.

• Wenn es keine Änderungen an Ihrem Code gibt, werden von Azure Pipelines vermutlich keine neuen Ausführungen gestartet. Erfahren Sie, wie Sie dieses Verhalten außer Kraft setzen.

Meine YAML-Zeitpläne haben gut funktioniert. Aber jetzt funktionieren sie nicht mehr. Wie kann ich das debuggen?

• Wenn Sie always:true nicht angegeben haben, wird Ihre Pipeline nicht geplant, es sei denn, Ihr Code wird aktualisiert. Überprüfen Sie, ob Codeänderungen aufgetreten sind und wie Sie die Zeitpläne konfiguriert haben.

• Es gibt ein Limitin Bezug darauf, wie oft Sie Ihre Pipeline planen können. Überprüfen Sie, ob Sie dieses Limit überschritten haben.

• Überprüfen Sie, ob jemand weitere Zeitpläne auf der Benutzeroberfläche aktiviert hat. Öffnen Sie den Editor für Ihre Pipeline, und wählen Sie Trigger aus. Wenn auf der Benutzeroberfläche Zeitpläne definiert wurden, werden Ihre YAML-Zeitpläne nicht berücksichtigt.

• Überprüfen Sie, ob die Pipeline angehalten oder deaktiviert wurde. Wählen Sie Einstellungen für Ihre Pipeline aus.

• Überprüfen Sie die nächsten Ausführungen, die Azure Pipelines für Ihre Pipeline geplant hat. Sie finden diese Ausführungen, indem Sie die Aktion Geplante Ausführungen in Ihrer Pipeline auswählen. Wenn die erwarteten Zeitpläne nicht angezeigt werden, nehmen Sie eine kleine unwichtige Änderung an Ihrer YAML-Datei vor, und pushen Sie das Update an Ihr Repository. Dadurch sollten die Zeitpläne neu synchronisiert werden.

• Wenn Sie GitHub zum Speichern Ihres Codes verwenden, ist es möglich, dass Azure Pipelines beim Versuch, eine neue Ausführung zu starten, von GitHub gedrosselt wurden. Überprüfen Sie, ob Sie manuell eine neue Ausführung starten können.

Mein Code hat sich nicht geändert, aber dennoch wird ein geplanter Build ausgelöst. Warum?

• Möglicherweise haben Sie die Option aktiviert, dass immer ein geplanter Build ausgeführt wird, auch wenn keine Codeänderungen vorhanden sind. Wenn Sie eine YAML-Datei verwenden, überprüfen Sie die Syntax für den Zeitplan in dieser Datei. Wenn Sie klassische Pipelines verwenden, überprüfen Sie, ob Sie diese Option in den Plantriggern aktiviert haben.

• Möglicherweise haben Sie die Buildpipeline oder eine Eigenschaft der Pipeline aktualisiert. Dies führt dazu, dass eine neue Ausführung geplant wird, auch wenn Sie den Quellcode nicht aktualisiert haben. Überprüfen Sie im klassischen Editor den Verlauf von Änderungen in der Pipeline.

• Möglicherweise haben Sie die Dienstverbindung aktualisiert, die zum Herstellen einer Verbindung mit dem Repository verwendet wird. Dies führt dazu, dass eine neue Ausführung geplant wird, auch wenn Sie den Quellcode nicht aktualisiert haben.

• Azure Pipelines überprüft zuerst, ob Updates für Ihren Code vorhanden sind. Wenn Azure Pipelines Ihr Repository nicht erreichen oder diese Informationen abrufen kann, wird eine Informationsausführung erstellt. Dabei handelt es sich um einen Dummybuild, um Sie darüber zu informieren, dass Azure Pipelines Ihr Repository nicht erreichen kann.

• Ihre Pipeline enthält möglicherweise keinen vollständig erfolgreichen Build. Um festzustellen, ob ein neuer Build geplant werden soll oder nicht, schlägt Azure DevOps den letzten vollständig erfolgreichen geplanten Build nach. Wenn der Dienst keinen solchen Build findet, löst er einen neuen geplanten Build aus. Teilweise erfolgreiche geplante Builds werden nicht als erfolgreich betrachtet. Wenn Ihre Pipeline also nur teilweise erfolgreiche Builds enthält, löst Azure DevOps geplante Builds aus, auch wenn sich Ihr Code nicht geändert hat.

Die geplante Ausführung wird im Bereich „Geplante Ausführungen“ angezeigt. Aber die Ausführung erfolgt nicht zu diesem Zeitpunkt. Warum?

• Im Bereich Geplante Ausführungen werden alle potenziellen Zeitpläne angezeigt. Diese werden jedoch möglicherweise nicht tatsächlich ausgeführt, es sei denn, Sie haben echte Updates am Code vorgenommen. Um die Ausführung eines Zeitplans zu erzwingen, stellen Sie sicher, dass Sie in der YAML-Pipeline die Eigenschaft Immer festgelegt bzw. in einer klassischen Pipeline die Option „Immer ausführen“ aktiviert haben.

In einer YAML-Pipeline definierte Zeitpläne funktionieren für einen Branch, aber nicht für den anderen. Wie kann ich dies korrigieren?

Zeitpläne werden in YAML-Dateien definiert, und diese Dateien sind Branches zugeordnet. Wenn eine Pipeline für einen bestimmten Branch geplant werden soll, z. B. features/X, stellen Sie sicher, dass für die YAML-Datei in diesem Branch der Cron-Zeitplan definiert wurde und dass die richtigen Branches für den Zeitplan in die Datei eingeschlossen wurden. Die YAML-Datei im features/X-Branch sollte in diesem Beispiel das folgende schedule-Element aufweisen:

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

Weitere Informationen finden Sie unter Überlegungen zu Branches für Plantrigger.