Konfigurowanie harmonogramów dla potoków

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

Usługa Azure Pipelines udostępnia kilka typów wyzwalaczy w celu skonfigurowania sposobu uruchamiania potoku.

• Zaplanowane wyzwalacze uruchamiają potok na podstawie harmonogramu, takiego jak kompilacja nocna. Ten artykuł zawiera wskazówki dotyczące używania zaplanowanych wyzwalaczy do uruchamiania potoków zgodnie z harmonogramem.
• Wyzwalacze zdarzeniowe uruchamiają potok w odpowiedzi na zdarzenia, takie jak tworzenie żądania ściągnięcia lub wysyłanie do gałęzi. Aby uzyskać informacje na temat korzystania z wyzwalaczy opartych na zdarzeniach, zobacz wyzwalacze w usłudze Azure Pipelines.

Możesz połączyć wyzwalacze zaplanowane i oparte na zdarzeniach w swoich potokach, na przykład w celu zweryfikowania kompilacji za każdym razem, gdy zostanie wykonane wypchnięcie (wyzwalacz ciągłej integracji), gdy zostanie złożone żądanie ściągnięcia (wyzwalacz żądania ściągnięcia), oraz podczas nocnej kompilacji (zaplanowany wyzwalacz). Jeśli chcesz zbudować przepływ wyłącznie według harmonogramu, a nie w odpowiedzi na triggery oparte na zdarzeniach, upewnij się, że przepływ nie ma żadnych innych triggerów. Na przykład potoki YAML w repozytorium GitHub mają domyślnie włączone wyzwalacze ciągłej integracji i wyzwalacze dla próśb o pobranie. Aby uzyskać informacje na temat wyłączania domyślnych wyzwalaczy, zobacz Wyzwalacze w usłudze Azure Pipelines i przejdź do sekcji dotyczącej typu repozytorium.

Zaplanowane wyzwalacze

YAML

Ważne

Zaplanowane wyzwalacze zdefiniowane przy użyciu interfejsu użytkownika ustawień potoku mają pierwszeństwo przed zaplanowanymi wyzwalaczami YAML.

Jeśli w potoku YAML istnieją zarówno wyzwalacze zaplanowane w YAML, jak i zaplanowane wyzwalacze zdefiniowane w interfejsie użytkownika, uruchamiane są tylko te zdefiniowane w interfejsie użytkownika. Aby uruchomić zdefiniowane zaplanowane wyzwalacze YAML w potoku YAML, należy usunąć zaplanowane wyzwalacze zdefiniowane w interfejsie użytkownika ustawień potoku. Po usunięciu wszystkich zaplanowanych wyzwalaczy interfejsu użytkownika należy wykonać wypychanie w celu rozpoczęcia oceny zaplanowanych wyzwalaczy YAML.

Aby usunąć zaplanowane wyzwalacze UI z potoku YAML, zobacz ustawienia UI zastępują zaplanowane wyzwalacze YAML.

Zaplanowane wyzwalacze konfigurują potok do uruchamiania zgodnie z harmonogramem zdefiniowanym przy użyciu składni cron.

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

Zaplanowane potoki w języku YAML mają następujące ograniczenia.

• Strefa czasowa harmonogramów cron to UTC. Możesz uzyskać pomoc AI z GitHub Copilot, aby tworzyć wyrażenia cron.
• Jeśli określisz klauzulę exclude bez klauzuli include dla branches, jest to równoważne określeniu * w klauzuli include.
• Nie można używać zmiennych potoku podczas określania harmonogramów.
• Jeśli używasz szablonów w pliku YAML, harmonogramy muszą być określone w głównym pliku YAML, a nie w plikach szablonów.

Zagadnienia dotyczące gałęzi dla zaplanowanych wyzwalaczy

Zaplanowane wyzwalacze są oceniane dla gałęzi po wystąpieniu następujących zdarzeń.

• Zostanie utworzony potok.
• Plik YAML potoku jest aktualizowany przy użyciu funkcji push lub poprzez edycję w edytorze potoku.
• Ścieżka pliku YAML potoku jest aktualizowana w celu odwołania się do innego pliku YAML. Ta zmiana aktualizuje tylko gałąź domyślną i dlatego pobiera tylko harmonogramy w zaktualizowanym pliku YAML dla gałęzi domyślnej. Jeśli inne gałęzie następnie scalą gałąź domyślną, na przykład git pull origin main, zaplanowane wyzwalacze z nowo przywoływanego pliku YAML są oceniane dla tej gałęzi.
• Zostanie utworzona nowa gałąź.

Gdy jedno z tych zdarzeń wystąpi w gałęzi, wszelkie zaplanowane uruchomienia dla tej gałęzi dodaje się, jeśli ta gałąź jest zgodna z filtrami gałęzi dotyczącymi zaplanowanych wyzwalaczy umieszczonymi w pliku YAML tej gałęzi.

Ważne

Zaplanowane uruchomienia dla gałęzi są dodawane tylko wtedy, gdy gałąź jest zgodna z filtrami gałęzi dla zaplanowanych wyzwalaczy w pliku YAML w tej gałęzi.

Na przykład pipeline jest tworzony z następującym harmonogramem, a ta wersja pliku YAML jest zapisana w gałęzi main. Ten plan buduje gałąź main na codziennej bazie.

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

Następnie zostanie utworzona nowa gałąź oparta na maino nazwie new-feature. Zaplanowane wyzwalacze z pliku YAML w nowej gałęzi są odczytywane i ponieważ nie ma dopasowania do gałęzi new-feature, żadne zmiany nie są wprowadzane do zaplanowanych kompilacji, a gałąź new-feature nie jest kompilowana przy użyciu zaplanowanego wyzwalacza.

Jeśli new-feature zostanie dodany do listy branches i ta zmiana zostanie wypchnięta do gałęzi new-feature, plik YAML zostanie odczytany, a ponieważ new-feature znajduje się teraz na liście gałęzi, zaplanowana kompilacja zostanie dodana dla gałęzi new-feature.

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

Teraz należy wziąć pod uwagę, że gałąź o nazwie release jest tworzona na podstawie main, a następnie release jest dodawana do filtrów gałęzi w pliku YAML w gałęzi main, ale nie w nowo utworzonej gałęzi release.

# 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

Ponieważ release został dodany do filtrów gałęzi w gałęzi main, ale nie do filtrów gałęzi w gałęzi release, gałąź release nie zostanie utworzona zgodnie z tym harmonogramem. Tylko wtedy, gdy gałąź release zostanie dodana do filtrów gałęzi w pliku YAML w gałęzi wydania, zaplanowana kompilacja zostanie dodana do harmonogramu.

Zagadnienia dotyczące usługi Batch dla zaplanowanych wyzwalaczy

Właściwość batch określa, czy uruchomić potok, gdy wcześniej zaplanowane uruchomienie jest w toku. Jeśli batch jest true, nowe uruchomienie potoku nie zostanie uruchomione z powodu harmonogramu, jeśli poprzednie uruchomienie potoku jest nadal w toku. Wartość domyślna to false.

Na właściwość batch wpływa ustawienie właściwości always. Gdy always jest true, potok jest uruchamiany zgodnie z harmonogramem cron, nawet jeśli batch jest true i jest uruchomiony w toku.

Zawsze	Porcja	Zachowanie
false	false	Potok danych jest uruchamiany tylko wtedy, gdy nastąpiła zmiana w odniesieniu do ostatniego pomyślnego zaplanowanego przebiegu procesu, nawet jeśli przetwarzanie z ostatniego zaplanowanego wyzwalacza jest w toku.
false	true	Potok jest uruchamiany tylko wtedy, gdy istnieje zmiana w odniesieniu do ostatniego pomyślnego zaplanowanego uruchomienia potoku i nie ma zaplanowanego uruchomienia potoku w toku.
true	false	Uruchomienie potoku odbywa się zgodnie z harmonogramem cronowym.
true	true	Przebiegi potoku zgodnie z harmonogramem cron, nawet jeśli istnieje przebieg w toku.

Build.CronSchedule.DisplayName zmienna

Gdy pipeline jest uruchomiony z powodu zaplanowanego uruchomienia cron, wstępnie zdefiniowana zmienna Build.CronSchedule.DisplayName zawiera displayName harmonogramu cron, który wyzwolił uruchomienie pipeline.

Twój potok YAML może zawierać wiele harmonogramów cron, i możesz chcieć, aby ten potok uruchamiał różne etapy lub zadania w zależności od tego, który harmonogram cron jest aktywny. Na przykład masz nocną kompilację i cotygodniową kompilację i chcesz uruchomić określony etap tylko podczas nocnej kompilacji. Możesz użyć zmiennej Build.CronSchedule.DisplayName w warunku zadania lub etapu, aby określić, czy uruchamiać to zadanie, czy etap.

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

Aby uzyskać więcej przykładów, zobacz przykłady schedules.cron.

Klasyczny

Wybierz dni i godziny uruchamiania kompilacji przy użyciu edytora klasycznego.

Jeśli repozytorium to Azure Repos Git, GitHub lub inne Git, możesz również określić gałęzie do uwzględnienia i wykluczenia. Jeśli chcesz użyć symboli wieloznacznych, wpisz specyfikację gałęzi (na przykład features/modules/*), a następnie naciśnij Enter.

Przykłady

YAML

W poniższym przykładzie zdefiniowano dwa harmonogramy:

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

Pierwszy harmonogram, kompilacja Daily midnight , uruchamia potok o północy każdego dnia, ale tylko wtedy, gdy kod uległ zmianie od ostatniego pomyślnego uruchomienia zaplanowanego, dla main i wszystkich gałęzi releases/*, z wyjątkiem gałęzi pod releases/ancient/*.

Drugi harmonogram, Cotygodniowa kompilacja niedzielna, uruchamia potok w niedziele w południe, niezależnie od tego, czy kod zmienił się od ostatniego uruchomienia, czy nie, dla wszystkich releases/* rozgałęzień.

Uwaga

Strefa czasowa dla harmonogramów cron to UTC, więc w tych przykładach build o północy i build w południe odbywają się o północy i w południe w czasie UTC.

Aby uzyskać więcej przykładów, zobacz Migrowanie z edytora klasycznego.

Klasyczny

Przykład: Nocna kompilacja repozytorium Git w wielu strefach czasowych

W tym przykładzie zaplanowany wyzwalacz edytora klasycznego zawiera dwa wpisy, które generują następujące kompilacje.

• Codziennie, od poniedziałku do piątku, o 3:00 nad ranem (strefa czasowa UTC + 5:30), kompiluj gałęzie, które spełniają kryteria filtra gałęzi features/india/*

  

• Od poniedziałku do piątku o godzinie 3:00 (strefa czasowa UTC -5), kompiluj gałęzie, które spełniają kryteria filtrowania gałęzi features/nc/*.

  

Przykład: Wersja testowa nocna z różnymi częstotliwościami

Azure Pipelines i Azure DevOps 2019 Server

W tym przykładzie klasyczny wyzwalacz harmonogramu w edytorze ma dwa wpisy, produkując następujące buildy.

• Co poniedziałek – piątek o 3:00 czasu UTC należy kompilować gałęzie spełniające kryteria filtrowania main i releases/*.

  

• Co niedzielę o 3:00 UTC zbuduj gałąź releases/lastversion, nawet jeśli źródło lub potok nie zmienił się.

  

Składnia Cron

YAML

Każde zaplanowane wyrażenie cron wyzwalacza usługi Azure Pipelines jest wyrażeniem rozdzielanym spacjami z pięcioma wpisami w następującej kolejności. Wyrażenie jest ujęte w pojedynczych cudzysłowach '.

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

Pole	Dopuszczalne wartości
Minuty	Od 0 do 59
Godziny	Od 0 do 23
Dni	Od 1 do 31
Miesiące	od 1 do 12, pełne nazwy angielskie, pierwsze trzy litery angielskich nazw
Dni tygodnia	od 0 do 6 (począwszy od niedzieli), pełne nazwy angielskie, pierwsze trzy litery angielskich nazwisk

Wartości mogą być w następujących formatach.

Forma	Przykład	Opis
Symbol wieloznaczny	*	Pasuje do wszystkich wartości dla tego pola
Pojedyncza wartość	5	Określa pojedynczą wartość dla tego pola
Oddzielone przecinkami	3,5,6	Określa wiele wartości dla tego pola. Można łączyć wiele formatów, takich jak 1,3-6
Zakresy	1-3	Włączający zakres wartości dla tego pola
Interwały	*/4 lub 1-5/2	Interwały zgodne dla tego pola, takie jak co czwarta wartość lub zakres 1–5 z interwałem kroku 2

Przykład	Wyrażenie Cron
Buduj co poniedziałek, środę i piątek o godzinie 18:00	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5 lub 0 18 * * 1-5/2
Kompilowanie co 6 godzin	0 0,6,12,18 * * *, 0 */6 * * * lub 0 0-18/6 * * *
Buduj co 6 godzin, zaczynając od 9:00 rano.	0 9,15,21 * * * lub 0 9-21/6 * * *

Aby uzyskać więcej informacji na temat obsługiwanych formatów, zobacz Crontab Expression.

Tworzenie wyrażenia cron za pomocą narzędzia GitHub Copilot

Możesz uzyskać pomoc dotyczącą sztucznej inteligencji od narzędzia GitHub Copilot w celu kompilowania wyrażeń cron lub konwertowania istniejących wyrażeń cron z lokalnej strefy czasowej na UTC.

Harmonogramy cron usługi Azure Pipelines są definiowane w czasie UTC, więc harmonogramy takie jak Kompilacja co poniedziałek, środę i piątek o godzinie 18:00 należy utworzyć przy użyciu składni cron i przekonwertować z lokalnej strefy czasowej na UTC.

Dostosuj poniższe polecenia, aby utworzyć wyrażenia cron lub przekonwertować wyrażenia cron na UTC ze strefy czasowej, której użyłeś do ich utworzenia.

W poniższym przykładzie Copilot zostaje poproszony o utworzenie harmonogramu cron w UTC, aby budowanie odbywało się w każdy poniedziałek, środę i piątek o godzinie 18:00 czasu wschodniego standardowego (EST).

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

Jeśli masz już wyrażenie cron w lokalnej strefie czasowej, możesz poprosić Copilot o przekonwertowanie go na utc. W tym przykładzie harmonogram cron do kompilacji co poniedziałek, środę i piątek o 18:00 (0 18 * * Mon,Wed,Fri) Wschodni czas standardowy jest konwertowany na UTC.

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

Konwertowanie wyrażenia cron na czas UTC może wymagać zmiany dni tygodnia w wyrażeniu. W poniższym przykładzie Copilot jest zachęcany do utworzenia harmonogramu cron UTC, aby działał od poniedziałku do piątku o godzinie 12:30 czasu środkowoeuropejskiego (CET). Środkowoeuropejski czas standardowy jest przed UTC, więc wynikowe wyrażenie rozpoczyna się późnym wieczorem w niedzielę, a nie wczesnym poniedziałkowym rankiem i kończy się w czwartek.

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

Aby uzyskać dodatkowe szczegóły dotyczące wyrażenia cron wygenerowanego przez Copilot, możesz poprosić Copilot o podanie wyjaśnienia wygenerowanego wyrażenia cron w swojej prośbie.

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 jest obsługiwany przez sztuczną inteligencję, więc możliwe są niespodzianki i błędy. Aby uzyskać więcej informacji, zobacz także Copilot często zadawane pytania dotyczące ogólnego użytkowania.

Klasyczny

Harmonogramy klasyczne są definiowane przy użyciu edytora graficznego zamiast składni cron. Aby uzyskać informacje na temat definiowania harmonogramów klasycznych, zobacz Przykłady.

Widok zaplanowanych biegów

YAML

Podgląd zaplanowanych uruchomień można wyświetlić, wybierając Zaplanowane uruchomienia z menu kontekstowego na stronie szczegółów potoku .

Ważne

Widok zaplanowanych przebiegów pokazuje tylko potoki zaplanowane do uruchomienia w ciągu siedmiu dni od bieżącej daty. Jeśli harmonogram cron ma interwał dłuższy niż 7 dni, a następne uruchomienie ma zostać uruchomione po siedmiu dniach od bieżącej daty, nie będzie wyświetlane w widoku Zaplanowane uruchomienia.

Menu

Po utworzeniu lub zaktualizowaniu zaplanowanych wyzwalaczy można je zweryfikować przy użyciu widoku zaplanowanych przebiegów.

W tym przykładzie przedstawiono planowane uruchomienia dla następującego harmonogramu.

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

W okienku Zaplanowane uruchomienia wyświetlane są czasy przekonwertowane na lokalną strefę czasową ustawioną na komputerze używanym do przeglądania portalu Azure DevOps. W tym przykładzie przedstawiono zrzut ekranu wykonany w strefie czasowej EST.

Uwaga

Jeśli zaktualizujesz harmonogram dla uruchamianego potoku, widok Zaplanowane uruchomienia nie zostanie zaktualizowany o nowy harmonogram, dopóki nie zakończy się aktualnie uruchamiany potok.

Klasyczny

Podgląd nadchodzących zaplanowanych kompilacji można wyświetlić, wybierając pozycję Zaplanowane uruchomienia z menu kontekstowego na stronie szczegółów potoku dla potoku.

menu

Po utworzeniu lub zaktualizowaniu zaplanowanych wyzwalaczy możesz je zweryfikować przy użyciu tego widoku.

Uruchamianie nawet wtedy, gdy nie ma żadnych zmian w kodzie

Domyślnie potok nie jest uruchamiany według harmonogramu, jeśli od ostatniego pomyślnego zaplanowanego uruchomienia nie nastąpiły żadne zmiany w kodzie. Należy na przykład wziąć pod uwagę, że zaplanowano uruchamianie potoku każdej nocy o godzinie 19:00. W dni robocze wprowadzasz różne zmiany w swoim kodzie. Rurociąg działa zgodnie z harmonogramem. W weekendy nie wprowadzasz żadnych zmian w kodzie. Jeśli nie nastąpiły żadne zmiany kodu od zaplanowanego uruchomienia w piątek, potok nie jest uruchamiany zgodnie z harmonogramem w weekend.

YAML

Aby wymusić uruchomienie potoku nawet w przypadku braku zmian w kodzie, możesz użyć słowa kluczowego always.

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

Klasyczny

Aby skonfigurować zaplanowany potok kompilacji tylko wtedy, gdy nastąpiła zmiana od ostatniej kompilacji, zaznacz Zaplanuj kompilacje tylko, jeśli zmieniło się źródło lub potok.

Limity liczby zaplanowanych uruchomień w potokach YAML

Istnieją pewne ograniczenia dotyczące częstotliwości planowanych uruchomień potoku. Te limity zostały wprowadzone, aby zapobiec niewłaściwemu użyciu zasobów usługi Azure Pipelines, szczególnie w przypadku agentów hostowanych przez firmę Microsoft. Oto te limity:

• około 1000 przebiegów na rurociąg tygodniowo
• 10 uruchomień na pipeline w ciągu 15 minut

Migrowanie z edytora klasycznego

W poniższych przykładach pokazano, jak migrować harmonogramy z edytora klasycznego do języka YAML.

• Przykład: nocne kompilowanie repozytorium Git w wielu strefach czasowych
• Przykład: nocna kompilacja z różnymi częstotliwościami

Przykład: Nocna kompilacja repozytorium Git w wielu strefach czasowych

W tym przykładzie, zaplanowany wyzwalacz w klasycznym edytorze ma dwa wpisy, co skutkuje powstaniem następujących kompilacji.

• Kompiluj gałęzie spełniające kryteria filtrowania gałęzi features/india/* o godzinie 3:00 w poniedziałki - piątki (strefa czasowa UTC + 5:30)

  

• Co poniedziałek - piątek o godzinie 3:00 (strefa czasowa UTC - 5:00), kompiluj gałęzie spełniające kryteria filtrowania gałęzi features/nc/*

  

Odpowiedni wyzwalacz zaplanowany YAML to:

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

W pierwszym harmonogramie M-F 3:00 (UTC + 5:30) Kompilacja dzienna Indii, składnia cron (mm HH DD MM DW) jest 30 21 * * Sun-Thu.

• Minuty i godziny — 30 21 — odnosi się do 21:30 UTC (9:30 PM UTC). Ponieważ określona strefa czasowa w edytorze klasycznym to UTC + 5:30, musimy odjąć 5 godzin i 30 minut od żądanego czasu kompilacji 3:00 rano, aby uzyskać pożądany czas UTC niezbędny do ustawienia wyzwalacza YAML. Możesz uzyskać pomoc dotyczącą sztucznej inteligencji z witryny GitHub Copilot, aby utworzyć wyrażenie cron.
• Dni i miesiące są określane jako symbole wieloznaczne, ponieważ ten harmonogram nie określa uruchamiania tylko w określonych dniach miesiąca lub w określonym miesiącu.
• Dni tygodnia — Sun-Thu — ze względu na konwersję strefy czasowej, aby nasze buildy uruchamiały się o godzinie 3:00 w indyjskiej strefie czasowej UTC + 5:30, musimy je zaplanować na poprzedni dzień w czasie UTC. Możemy również określić dni tygodnia jako 0-4 lub 0,1,2,3,4.

W drugim harmonogramie M-F 3:00 AM (UTC - 5) dzienna kompilacja NC, składnia crona to 0 8 * * Mon-Fri.

• Minuty i godziny — 0 8 — to mapuje 8:00 AM UTC. Ponieważ określona strefa czasowa w edytorze klasycznym to UTC - 5:00, musimy dodać 5 godzin do żądanego czasu kompilacji o 3:00 rano, aby uzyskać odpowiednią godzinę UTC do określenia dla wyzwalacza YAML. Możesz uzyskać pomoc dotyczącą sztucznej inteligencji z witryny GitHub Copilot, aby utworzyć wyrażenie cron.
• Dni i miesiące traktowane są jako symbole wieloznaczne, gdyż harmonogram ten nie określa uruchamiania jedynie w konkretnych dniach miesiąca lub w wybranym miesiącu.
• Dni tygodnia — Mon-Fri — ponieważ nasze konwersje strefy czasowej nie obejmują wielu dni tygodnia dla żądanego harmonogramu, nie musimy tutaj wykonywać żadnej konwersji. Możemy również określić dni tygodnia jako 1-5 lub 1,2,3,4,5.

Ważne

Strefy czasowe UTC w zaplanowanych wyzwalaczach YAML nie uwzględniają czasu letniego.

Wskazówka

W przypadku używania 3-literowych dni tygodnia i chcąc przedziału wielu dni do niedzieli, niedzielę należy uznać za pierwszy dzień tygodnia, np. dla harmonogramu od północy EST, od czwartku do niedzieli, składnia cron to 0 5 * * Sun,Thu-Sat.

Przykład: Kompilacja nocna z różnymi częstotliwościami

W tym przykładzie wyzwalacz zaplanowany w edytorze klasycznym ma dwa wpisy, tworząc następujące kompilacje.

• Co poniedziałek — piątek o 3:00 czasu UTC, buduj gałęzie, które spełniają kryteria filtrowania main i releases/*.

  

• Każdą niedzielę o 3:00 czasu UTC kompiluj gałąź releases/lastversion, nawet jeśli kod źródłowy ani potok nie uległy zmianie

  

Wyzwalacz zaplanowany w YAML jest równoważny:

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

W pierwszym harmonogramie , kompilacja dzienna M-F o 3:00 (UTC), składnia cron jest: 0 3 * * Mon-Fri.

• Minuty i godziny — 0 3 — to mapuje 3:00 AM UTC. Ponieważ określona strefa czasowa w edytorze klasycznym jest UTC, nie musimy wykonywać żadnych konwersji strefy czasowej.
• Dni i miesiące są określane jako symbole wieloznaczne, ponieważ harmonogram ten nie precyzuje uruchamiania tylko w wybrane dni miesiąca ani w wybranym miesiącu.
• Dni tygodnia — Mon-Fri — ponieważ nie ma konwersji strefy czasowej, dni tygodnia są mapowane bezpośrednio według harmonogramu edytora klasycznego. Możemy również określić dni tygodnia jako 1,2,3,4,5.

W drugim harmonogramie niedziela 3:00 (UTC) cotygodniowe budowanie najnowszej wersji, składnia cron to 0 3 * * Sun.

• Minuty i godziny — 0 3 — odnosi się do 3:00 AM UTC. Ponieważ określona strefa czasowa w edytorze klasycznym jest UTC, nie musimy wykonywać żadnych konwersji strefy czasowej.
• Dni i miesiące są traktowane jako symbole wieloznaczne, ponieważ ten harmonogram nie wymaga uruchamiania tylko w określonych dniach miesiąca ani w określonym miesiącu.
• Dni tygodnia — Sun — ponieważ nasze konwersje strefy czasowej nie obejmują wielu dni tygodnia dla żądanego harmonogramu, nie musimy tutaj wykonywać żadnej konwersji. Możemy również określić dni tygodnia jako 0.
• Określamy również always: true, ponieważ ta kompilacja ma zostać uruchomiona niezależnie od tego, czy kod źródłowy został zaktualizowany.

Często zadawane pytania

• Chcę, aby mój pipeline był uruchamiany tylko zgodnie z harmonogramem, a nie wtedy, gdy zmiana zostanie wypchnięta do gałęzi
• Zdefiniowałem harmonogram w pliku YAML. Ale to nie działało. Co się stało?
• Moje harmonogramy YAML działały prawidłowo. Ale przestali teraz pracować. Jak to debugować?
• Mój kod nie uległ zmianie, ale jest wyzwalana zaplanowana kompilacja. Dlaczego?
• Widzę planowany przebieg w panelu Zaplanowane uruchomienia. Jednak nie jest ona uruchamiana w tym czasie. Dlaczego?
• Harmonogramy zdefiniowane w potoku YAML działają dla jednej gałęzi, ale nie dla drugiej. Jak to naprawić?

Chcę, aby mój pipeline był uruchamiany tylko zgodnie z harmonogramem, a nie wtedy, gdy ktoś zatwierdza zmianę w gałęzi.

Jeśli chcesz, aby potok był uruchamiany tylko zgodnie z harmonogramem, a nie wtedy, gdy ktoś wypycha zmianę do gałęzi lub scala zmianę do gałęzi głównej, musisz jawnie wyłączyć domyślne wyzwalacze CI i PR.

Aby wyłączyć domyślne wyzwalacze ciągłej integracji i żądania ściągnięcia, dodaj następujące instrukcje do potoku YAML, a sprawdzić, czy wyzwalacze potoku YAML nie zostały zastąpione za pomocą wyzwalaczy interfejsu użytkownika.

trigger: none
pr: none

Aby uzyskać więcej informacji, zobacz definicję pr i definicję wyzwalacza .

Zdefiniowałem harmonogram w pliku YAML. Ale to nie działało. Co się stało?

• Sprawdź następne przebiegi zaplanowane przez Azure Pipelines dla twojej pipeline. Można znaleźć te uruchomienia, wybierając akcję Zaplanowane uruchomienia w swoim potoku. Lista jest filtrowana, aby pokazać tylko kilka nadchodzących przebiegów w ciągu najbliższych dni. Jeśli to nie spełnia oczekiwań, prawdopodobnie jest to przypadek, że harmonogram cron został nieprawidłowo wtypowany lub nie masz harmonogramu zdefiniowanego w odpowiedniej gałęzi. Przeczytaj powyższy temat, aby dowiedzieć się, jak skonfigurować harmonogramy. Przeszacuj składnię cron. Wszystkie czasy harmonogramów cron znajdują się w formacie UTC.

• Wprowadź niewielką drobną zmianę w pliku YAML i wypchnij aktualizację do repozytorium. Jeśli wystąpił jakikolwiek problem podczas odczytywania harmonogramów z pliku YAML wcześniej, powinien zostać rozwiązany teraz.

• Jeśli masz jakiekolwiek harmonogramy zdefiniowane w interfejsie użytkownika, harmonogramy YAML nie są honorowane. Upewnij się, że nie masz żadnych harmonogramów UI, wchodząc do edytora potoku, a następnie wybierz Wyzwalacze.

• Istnieje limit liczby przebiegów, które można zaplanować dla potoku. Przeczytaj więcej na temat limitów .

• Jeśli nie ma żadnych zmian w kodzie, usługa Azure Pipelines może nie uruchamiać nowych przebiegów. Dowiedz się, jak zastąpić tego zachowania.

Moje harmonogramy YAML działały prawidłowo. Ale przestali teraz pracować. Jak to debugować?

• Jeśli nie określiłeś always:true, potok nie zostanie zaplanowany, chyba że zostaną wprowadzone jakiekolwiek zmiany w twoim kodzie. Sprawdź, czy były jakieś zmiany w kodzie i jak skonfigurowałeś harmonogramy.

• Istnieje limit, ile razy można zaplanować potok. Sprawdź, czy przekroczono te limity.

• Sprawdź, czy ktoś włączył więcej harmonogramów w interfejsie użytkownika. Otwórz edytor dla swojego potoku i wybierz Wyzwalacze. Jeśli zdefiniowano harmonogramy w interfejsie użytkownika, harmonogramy YAML nie zostaną uznane.

• Sprawdź, czy pipeline jest wstrzymany lub wyłączony. Wybierz pozycję Ustawienia dla pipeline.

• Sprawdź kilka następnych przebiegów zaplanowanych przez usługę Azure Pipelines dla potoku. Te uruchomienia można znaleźć, wybierając akcję Zaplanowane uruchomienia w potoku. Jeśli nie widzisz oczekiwanych harmonogramów, wprowadź niewielką drobną zmianę w pliku YAML i wypchnij aktualizację do repozytorium. Powinno to zostać ponownie zsynchronizowane z harmonogramami.

• Jeśli używasz usługi GitHub do przechowywania kodu, możliwe, że usługa Azure Pipelines mogła zostać ograniczona przez usługę GitHub podczas próby uruchomienia nowego uruchomienia. Sprawdź, czy możesz uruchomić nowy proces ręcznie.

Mój kod nie uległ zmianie, ale jest wyzwalana zaplanowana kompilacja. Dlaczego?

• Być może włączyłeś opcję zawsze uruchamiać zaplanowaną kompilację, nawet jeśli nie ma żadnych zmian w kodzie. Jeśli używasz pliku YAML, sprawdź składnię harmonogramu w pliku YAML. Jeśli używasz potoków klasycznych, sprawdź, czy zaznaczyłeś tę opcję w zaplanowanych wyzwalaczach.

• Być może zaktualizowano potok kompilacji lub pewną właściwość pipeline'u. Spowoduje to zaplanowanie nowego uruchomienia, nawet jeśli kod źródłowy nie został zaktualizowany. Sprawdź historię zmian w ciągu przy użyciu edytora klasycznego.

• Być może zaktualizowano połączenie usługi używane do łączenia z repozytorium. Spowoduje to zaplanowanie nowego uruchomienia, nawet jeśli kod źródłowy nie został zaktualizowany.

• Usługa Azure Pipelines najpierw sprawdza, czy istnieją jakiekolwiek aktualizacje kodu. Jeśli usługa Azure Pipelines nie może uzyskać dostępu do repozytorium lub uzyskać te informacje, spowoduje to utworzenie przebiegu informacyjnego. Jest to fikcyjna kompilacja, która poinformuje Cię, że usługa Azure Pipelines nie może nawiązać połączenia z repozytorium.

• Twoje pipeline może nie zakończyć się całkowicie pomyślną budową. Aby określić, czy zaplanować nową kompilację, czy nie, usługa Azure DevOps wyszukuje ostatnio pomyślnie zaplanowaną kompilację. Jeśli go nie znajdzie, wyzwala nową zaplanowaną kompilację. Częściowo pomyślne zaplanowane kompilacje nie są uznawane za pomyślne, więc jeśli potok ma tylko częściowo pomyślne kompilacje, usługa Azure DevOps wyzwoli zaplanowane kompilacje, nawet jeśli kod nie uległ zmianie.

Widzę planowane uruchomienie w panelu Zaplanowane uruchomienia. Jednak nie jest ona uruchamiana w tym czasie. Dlaczego?

• Na panelu Zaplanowane przejazdy są wyświetlane wszystkie potencjalne harmonogramy. Może to jednak nie zostać uruchomione, chyba że wprowadzono prawdziwe aktualizacje kodu. Aby wymusić, aby harmonogram zawsze się uruchamiał, upewnij się, że ustawiono właściwość zawsze w potoku YAML lub zaznaczono opcję zawsze uruchamiana w potoku klasycznym.

Harmonogramy zdefiniowane w potoku YAML działają dla jednej gałęzi, ale nie dla innej. Jak to naprawić?

Harmonogramy są definiowane w plikach YAML, a te pliki są skojarzone z gałęziami. Jeśli chcesz, aby potok był zaplanowany dla określonej gałęzi, na przykład features/X, upewnij się, że plik YAML w tej gałęzi ma zdefiniowany harmonogram cron i zawiera poprawne uwzględnienia gałęzi dla tego harmonogramu. Plik YAML w gałęzi features/X powinien mieć następujące schedule w tym przykładzie:

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

Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące gałęzi dla ustalonych wyzwalaczy.