Konfigurieren von Zeitplänen für Pipelines

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines bietet mehrere Arten von Triggern, um zu konfigurieren, wie Ihre Pipeline gestartet wird.

• Geplante Trigger starten Ihre Pipeline basierend auf einem Zeitplan, z. B. einem nächtlichen Build. Dieser Artikel enthält Anleitungen zur Verwendung geplanter Trigger zum Ausführen Ihrer Pipelines basierend auf einem Zeitplan.
• Ereignisbasierte Trigger starten Ihre Pipeline als Reaktion auf Ereignisse, z. B. das Erstellen einer Pullanforderung oder das Pushen an eine Verzweigung. Informationen zur Verwendung ereignisbasierter Trigger finden Sie unter Trigger in Azure Pipelines.

Sie können geplante und ereignisbasierte Trigger in Ihren Pipelines kombinieren, um z. B. den Build jedes Mal zu überprüfen, wenn ein Push (CI-Trigger) erfolgt, wenn eine Pullanforderung (PR-Trigger) und ein nächtlicher Build (geplanter Trigger) erfolgt. Wenn Sie Ihre Pipeline nur in einem Zeitplan erstellen möchten und nicht als Reaktion auf ereignisbasierte Trigger, stellen Sie sicher, dass ihre Pipeline keine anderen Trigger aktiviert hat. Beispielsweise verfügen YAML-Pipelines in einem GitHub-Repository über CI-Trigger und PR-Trigger, die standardmäßig aktiviert sind. Informationen zum Deaktivieren von Standardtriggern finden Sie unter "Trigger in Azure Pipelines ", und navigieren Sie zu dem Abschnitt, der Ihren Repositorytyp abdeckt.

Geplante Auslöser

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 or pipeline settings changes since the last successful scheduled run. The default is false.

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 or pipeline settings 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

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

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

# 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

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

Examples

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

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

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

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

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

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

Ansicht "Geplante Ausführung"

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

Wird auch ausgeführt, wenn keine Codeänderungen vorhanden sind

Standardmäßig wird Die Pipeline nicht wie geplant ausgeführt, wenn seit der letzten erfolgreichen geplanten Ausführung keine Codeänderungen vorgenommen wurden. Denken Sie beispielsweise daran, dass Sie eine Pipeline für jede Nacht um 19:00 Uhr geplant haben. Während der Wochentage übertragen Sie verschiedene Änderungen an Ihren Code. Die Pipeline wird pro Zeitplan ausgeführt. Während der Wochenenden nehmen Sie keine Änderungen an Ihrem Code vor. Wenn seit der geplanten Ausführung am Freitag keine Codeänderungen vorgenommen wurden, wird die Pipeline während des Wochenendes nicht wie geplant ausgeführt.

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

Migrieren aus dem klassischen Editor

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

• Beispiel: Nightly Build of Git Repo in mehreren Zeitzonen
• Beispiel: Nachtbau mit unterschiedlichen Frequenzen

Beispiel: Nightly Build of Git Repo in mehreren Zeitzonen

In diesem Beispiel hat der geplante klassische Editorauslöser zwei Einträge, wodurch die folgenden Builds erstellt werden.

• Jeden Montag - Freitag um 3:00 Uhr (UTC + 5:30 Zeitzone), erstellen Sie Verzweigungen, die die Verzweigungsfilterkriterien features/india/* erfüllen

  

• Jeden Montag - Freitag um 3:00 Uhr (UTC - 5:00 Zeitzone), erstellen Sie Verzweigungen, die den Verzweigungsfilterkriterien features/nc/* entsprechen

  

Der entsprechende geplante YAML-Trigger 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) Indien täglich Build, ist die Cron-Syntax (mm HH DD MM DW) .30 21 * * Sun-Thu

• Minuten und Stunden - 30 21 Dies ist (21:30 UTC9:30 PM UTC) zugeordnet. Da die angegebene Zeitzone im klassischen Editor UTC + 5:30 lautet, müssen wir 5 Stunden und 30 Minuten von der gewünschten Buildzeit von 3:00 Uhr subtrahieren, um zur gewünschten UTC-Zeit einzutreffen, um für den YAML-Trigger anzugeben. Sie können KI-Unterstützung von GitHub Copilot erhalten, um Ihren Cron-Ausdruck zu erstellen.
• Tage und Monate werden als Wildcards angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder an einem bestimmten Monat ausgeführt werden soll.
• Tage der Woche - Sun-Thu aufgrund der Zeitzonenkonvertierung, für unsere Builds, die um 3:00 Uhr in der UTC + 5:30 Indien Zeitzone ausgeführt werden sollen, müssen wir angeben, dass sie den vorherigen Tag in UTC-Zeit beginnen. Wir könnten auch die Wochentage als 0-4 oder 0,1,2,3,4.

Im zweiten Zeitplan, M-F 3:00 AM (UTC - 5) NC täglich Build, ist 0 8 * * Mon-Fridie Cron-Syntax .

• Minuten und Stunden - 0 8 Dies ist zugeordnet 8:00 AM UTC. Da die angegebene Zeitzone im klassischen Editor UTC - 5:00 ist, müssen wir 5 Stunden von der gewünschten Buildzeit von 3:00 Uhr hinzufügen, um zur gewünschten UTC-Zeit einzutreffen, um für den YAML-Trigger anzugeben. Sie können KI-Unterstützung von GitHub Copilot erhalten, um Ihren Cron-Ausdruck zu erstellen.
• Tage und Monate werden als Wildcards angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder an einem bestimmten Monat ausgeführt werden soll.
• Wochentage - Mon-Fri Da sich unsere Zeitzonenkonvertierungen nicht über mehrere Wochentage für unseren gewünschten Zeitplan erstrecken, müssen wir hier keine Konvertierung durchführen. Wir könnten auch die Wochentage als 1-5 oder 1,2,3,4,5.

Beispiel: Nachtbau mit unterschiedlichen Frequenzen

In diesem Beispiel hat der geplante klassische Editorauslöser zwei Einträge, wodurch die folgenden Builds erstellt werden.

• Jeden Montag - Freitag um 3:00 Uhr UTC erstellen Sie Zweigniederlassungen, die die Kriterien für die main Verzweigungsfilter erfüllen.releases/*

  

• Jeden Sonntag um 3:00 Uhr UTC erstellen Sie die releases/lastversion Zweigstelle, auch wenn sich die Quelle oder Pipeline nicht geändert hat.

  

Der entsprechende geplante YAML-Trigger 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) täglichen Build, ist 0 3 * * Mon-Fridie Cron-Syntax .

• Minuten und Stunden - 0 3 Dies ist zugeordnet 3:00 AM UTC. Da die angegebene Zeitzone im klassischen Editor UTC ist, müssen keine Zeitzonenkonvertierungen ausgeführt werden.
• Tage und Monate werden als Wildcards angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder an einem bestimmten Monat ausgeführt werden soll.
• Wochentage - Mon-Fri da es keine Zeitzonenkonvertierung gibt, die Wochentage direkt aus dem klassischen Editor-Zeitplan. Wir könnten auch die Wochentage angeben als 1,2,3,4,5.

Im zweiten Zeitplan, Sonntag, 3:00 Uhr (UTC) wöchentlich neueste Version Build, ist 0 3 * * Sundie Cron-Syntax .

• Minuten und Stunden - 0 3 Dies ist zugeordnet 3:00 AM UTC. Da die angegebene Zeitzone im klassischen Editor UTC ist, müssen keine Zeitzonenkonvertierungen ausgeführt werden.
• Tage und Monate werden als Wildcards angegeben, da dieser Zeitplan nicht an bestimmten Tagen des Monats oder an einem bestimmten Monat ausgeführt werden soll.
• Wochentage - Sun Da sich unsere Zeitzonenkonvertierungen nicht über mehrere Wochentage für unseren gewünschten Zeitplan erstrecken, müssen wir hier keine Konvertierung durchführen. Wir könnten auch die Wochentage angeben als 0.
• Außerdem wird angegeben always: true , dass dieser Build ausgeführt werden soll, ob der Quellcode aktualisiert wurde.

Häufig gestellte Fragen

• Ich möchte, dass meine Pipeline nur im Zeitplan ausgeführt wird und nicht, wenn jemand eine Änderung an eine Verzweigung überträgt
• Ich habe einen Zeitplan in der YAML-Datei definiert. Aber es wurde nicht ausgeführt. Was ist passiert?
• Meine YAML-Zeitpläne funktionieren gut. Aber sie funktionieren jetzt nicht mehr. Wie kann ich dies debuggen?
• Mein Code hat sich noch nicht geändert, aber ein geplanter Build wird ausgelöst. Why?
• Die geplante Ausführung wird im Bereich "Geplante Ausführung" angezeigt. Es wird jedoch zu diesem Zeitpunkt nicht ausgeführt. Why?
• In yaML-Pipeline definierte Zeitpläne funktionieren für eine Verzweigung, aber nicht für die andere. Wie kann ich dieses Problem beheben?

Ich möchte, dass meine Pipeline nur im Zeitplan ausgeführt wird und nicht, wenn jemand eine Änderung an eine Verzweigung überträgt

Wenn Ihre Pipeline nur im Zeitplan ausgeführt werden soll und nicht, wenn jemand eine Änderung an eine Verzweigung überträgt oder eine Änderung an der Hauptverzweigung zusammenführt, müssen Sie die Standard-CI- und PR-Trigger für die Pipeline explizit deaktivieren.

Um die standardmäßigen CI- und PR-Trigger zu deaktivieren, fügen Sie der YAML-Pipeline die folgenden Anweisungen hinzu, und stellen Sie sicher, dass Sie die YAML-Pipelinetrigger nicht mit UI-Triggern überschrieben haben.

trigger: none
pr: none

Weitere Informationen finden Sie unter pr-Definition und Triggerdefinition.

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

• Überprüfen Sie die nächsten Ausführungen, die Azure-Pipelines für Ihre Pipeline geplant haben. Sie finden diese Ausführungen, indem Sie die Aktion "Geplante Ausführung " in Ihrer Pipeline auswählen. Die Liste wird nach unten gefiltert, um ihnen nur die bevorstehenden Läufe in den nächsten Tagen anzuzeigen. Wenn dies nicht Ihren Erwartungen entspricht, ist es wahrscheinlich der Fall, dass Sie Ihren Cron-Zeitplan falsch eingegeben haben, oder Sie haben den Zeitplan nicht in der richtigen Verzweigung definiert. Lesen Sie das obige Thema, um zu verstehen, wie Zeitpläne konfiguriert werden. Überprüfen Sie die Cronsyntax erneut. Alle Zeiten für Cron-Zeitpläne befinden sich in UTC.

• Nehmen Sie eine kleine triviale Änderung an Ihrer YAML-Datei vor, und übertragen Sie dieses Update in Ihr Repository. Wenn es ein Problem beim Lesen der Zeitpläne aus der YAML-Datei früher gab, sollte es jetzt behoben werden.

• Wenn In der Benutzeroberfläche Zeitpläne definiert sind, werden Ihre YAML-Zeitpläne nicht berücksichtigt. Stellen Sie sicher, dass sie keine UI-Zeitpläne haben, indem Sie zum Editor für Ihre Pipeline navigieren und dann Trigger auswählen.

• Es gibt ein Limit für die Anzahl der Ausführungen, die Sie für eine Pipeline planen können. Weitere Informationen zu Grenzwerten.

• Wenn es keine Änderungen an Ihrem Code gibt, werden möglicherweise keine neuen Ausführungsläufe von Azure Pipelines gestartet. Erfahren Sie, wie Sie dieses Verhalten außer Kraft setzen .

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

• Wenn Sie dies nicht angegeben always:truehaben, wird Ihre Pipeline nicht geplant, es sei denn, es werden Aktualisierungen an Ihrem Code vorgenommen. Überprüfen Sie, ob Codeänderungen vorgenommen wurden und wie Sie die Zeitpläne konfiguriert haben.

• Es gibt eine Beschränkung , wie oft Sie Ihre Pipeline planen können. Überprüfen Sie, ob Sie diese Grenzwerte überschritten haben.

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

• Überprüfen Sie, ob Die Pipeline angehalten oder deaktiviert ist. 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 haben. Sie finden diese Ausführungen, indem Sie die Aktion "Geplante Ausführung " in Ihrer Pipeline auswählen. Wenn die erwarteten Zeitpläne nicht angezeigt werden, nehmen Sie eine kleine triviale Änderung an Ihrer YAML-Datei vor, und übertragen Sie das Update an Ihr Repository. Dies sollte die Zeitpläne neu synchronisieren.

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

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

• Möglicherweise haben Sie eine Option aktiviert, um immer einen geplanten Build auszuführen, auch wenn keine Codeänderungen vorhanden sind. Wenn Sie eine YAML-Datei verwenden, überprüfen Sie die Syntax für den Zeitplan in der YAML-Datei. Wenn Sie klassische Pipelines verwenden, überprüfen Sie, ob Sie diese Option in den geplanten Triggern 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 den Verlauf der Änderungen in der Pipeline mithilfe des klassischen Editors.

• 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. Es ist ein Dummy-Build, um Sie darüber zu informieren, dass Azure Pipelines Ihr Repository nicht erreichen kann.

• Ihre Pipeline verfügt möglicherweise nicht über einen vollständig erfolgreichen Build. Um festzustellen, ob ein neuer Build geplant werden soll oder nicht, sucht Azure DevOps den letzten vollständig erfolgreichen geplanten Build. Wenn es keinen gefunden hat, löst es einen neuen geplanten Build aus. Teilweise erfolgreiche geplante Builds werden nicht als erfolgreich betrachtet. Wenn Ihre Pipeline also nur teilweise erfolgreiche Builds aufweist, 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ührung" angezeigt. Es wird jedoch zu diesem Zeitpunkt nicht ausgeführt. Why?

• Im Bereich "Geplante Ausführung " werden alle potenziellen Zeitpläne angezeigt. Es kann jedoch nicht tatsächlich ausgeführt werden, es sei denn, Sie haben echte Aktualisierungen am Code vorgenommen. Um die Ausführung eines Zeitplans zu erzwingen, stellen Sie sicher, dass Sie die Eigenschaft immer in der YAML-Pipeline festgelegt haben, oder aktivieren Sie die Option, immer in einer klassischen Pipeline auszuführen.

In yaML-Pipeline definierte Zeitpläne funktionieren für eine Verzweigung, aber nicht für die andere. Wie kann ich dieses Problem beheben?

Zeitpläne werden in YAML-Dateien definiert, und diese Dateien sind Verzweigungen zugeordnet. Wenn eine Pipeline für eine bestimmte Verzweigung geplant werden soll, sagen features/XSie, stellen Sie sicher, dass die YAML-Datei in dieser Verzweigung den cron-Zeitplan darin definiert hat und dass sie über die richtigen Verzweigungseinschlüsse für den Zeitplan verfügt. Die YAML-Datei in der features/X Verzweigung sollte folgendes in diesem Beispiel aufweisen schedule :

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

Weitere Informationen finden Sie unter Branch-Überlegungen für geplante Trigger.