Konfigurieren von Zeitplänen für Pipelines

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.

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.

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.