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 na podstawie harmonogramu.
• Wyzwalacze oparte na zdarzeniach uruchamiają potok w odpowiedzi na zdarzenia, takie jak tworzenie żądania ściągnięcia lub wypychanie 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ć zaplanowane i oparte na zdarzeniach wyzwalacze w potokach, na przykład w celu zweryfikowania kompilacji za każdym razem, gdy wypchnięcie (wyzwalacz ciągłej integracji), po wysłaniu żądania ściągnięcia (wyzwalacz żądania ściągnięcia) i nocnej kompilacji (wyzwalacz zaplanowany). Jeśli chcesz skompilować potok tylko zgodnie z harmonogramem, a nie w odpowiedzi na wyzwalacze oparte na zdarzeniach, upewnij się, że potok nie ma żadnych innych wyzwalaczy. Na przykład potoki YAML w repozytorium GitHub mają domyślnie włączone wyzwalacze ciągłej integracji i wyzwalacze żądania ściągnięcia. Aby uzyskać informacje na temat wyłączania wyzwalaczy domyślnych, 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 zaplanowane wyzwalacze YAML, jak i zdefiniowane zaplanowane wyzwalacze interfejsu użytkownika, uruchamiane są tylko zdefiniowane zaplanowane wyzwalacze interfejsu 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 interfejsu użytkownika z potoku YAML, zobacz Ustawienia interfejsu użytkownika 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 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.
• Jeśli określisz klauzulę exclude bez include klauzuli dla branches, jest ona równoważna określeniu * w klauzuli include .
• Podczas określania harmonogramów nie można używać zmiennych potoku.
• 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 z wypychania lub edytując go 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łąź.

Po wystąpieniu jednego z tych zdarzeń w gałęzi wszystkie zaplanowane uruchomienia dla tej gałęzi zostaną dodane, jeśli ta gałąź jest zgodna z filtrami gałęzi dla zaplanowanych wyzwalaczy zawartych w pliku YAML w 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 potok jest tworzony przy użyciu następującego harmonogramu, a ta wersja pliku YAML jest zaewidencjonowana w main gałęzi . Ten harmonogram tworzy main gałąź codziennie.

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

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

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

# 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 main gałęzi, ale nie w nowo utworzonej release gałęzi.

# 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 main gałęzi, ale nie do filtrów gałęzi w release gałęzi, release gałąź nie zostanie utworzona zgodnie z tym harmonogramem. Tylko wtedy, gdy release gałąź 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 należy uruchomić potok, jeśli wcześniej zaplanowane uruchomienie jest w toku; wartość domyślna to false. Dzieje się tak niezależnie od wersji repozytorium potoku.

W poniższej tabeli opisano sposób always i batch interakcję.

Zawsze	Batch	Zachowanie
false	false	Potok jest uruchamiany tylko wtedy, gdy istnieje zmiana w odniesieniu do ostatniego pomyślnego zaplanowanego uruchomienia potoku.
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	Potok działa zgodnie z harmonogramem cron.
true	true	Potok działa zgodnie z harmonogramem cron.

Ważne

Gdy always parametr ma truewartość , potok jest uruchamiany zgodnie z harmonogramem cron, nawet jeśli batch ma wartość true.

Build.CronSchedule.DisplayName, zmienna

Gdy potok jest uruchomiony z powodu zaplanowanego wyzwalacza cron, wstępnie zdefiniowana Build.CronSchedule.DisplayName zmienna zawiera displayName harmonogram cron, który wyzwolił uruchomienie potoku.

Potok YAML może zawierać wiele harmonogramów cron i możesz chcieć, aby potok uruchamiał różne etapy lub zadania na podstawie harmonogramu cron. 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 Usługa Azure Repos Git, GitHub lub Inna usługa 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 klawisz 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 zmienił się od czasu ostatniego zaplanowanego uruchomienia, dla main i wszystkich releases/* gałęzi, z wyjątkiem gałęzi w obszarze releases/ancient/*.

Drugi harmonogram, kompilacja Weekly Sunday, uruchamia potok w południe w niedziele, niezależnie od tego, czy kod uległ zmianie, czy nie od ostatniego uruchomienia, dla wszystkich releases/* gałęzi.

Uwaga

Strefa czasowa harmonogramów cron to UTC, więc w tych przykładach kompilacja północy i kompilacja południe są o północy i południe w formacie 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.

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

  

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

  

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

Azure Pipelines i Azure DevOps 2019 Server

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, gałęzie kompilacji spełniające kryteria filtrowania main gałęzi i releases/*

  

• Co niedzielę o 3:00 czasu UTC skompiluj releases/lastversion gałąź, nawet jeśli źródło lub potok nie uległ zmianie

  

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 pojedyncze cudzysłowy '.

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.

Format	Przykład	opis
Symbole wieloznaczne	*	Pasuje do wszystkich wartości dla tego pola
Pojedyncza wartość	5	Określa pojedynczą wartość dla tego pola
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	Zakres włącznie 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
Kompiluj 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 * * *lub 0 */6 * * *0 0-18/6 * * *
Kompilacja co 6 godzin, począwszy od godziny 9:00	0 9,15,21 * * * lub 0 9-21/6 * * *

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

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 przebiegów

YAML

Możesz wyświetlić podgląd nadchodzących zaplanowanych kompilacji, wybierając pozycję Zaplanowane uruchomienia z menu kontekstowego na stronie szczegółów potoku dla 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ępny przebieg ma zostać uruchomiony po siedmiu dniach od bieżącej daty, nie będzie wyświetlany w widoku Zaplanowane uruchomienia .

Po utworzeniu lub zaktualizowaniu zaplanowanych wyzwalaczy można je zweryfikować przy użyciu widoku Zaplanowane uruchomienia .

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

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

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

Uwaga

Jeśli zaktualizujesz harmonogram uruchamiania potoku, widok Zaplanowane uruchomienia nie zostanie zaktualizowany o nowy harmonogram do czasu ukończenia aktualnie uruchomionego potoku.

Klasyczny

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

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 zgodnie z harmonogramem, jeśli od ostatniego zaplanowanego uruchomienia nie nastąpiły żadne zmiany kodu. Należy na przykład wziąć pod uwagę, że zaplanowano uruchamianie potoku każdej nocy o godzinie 19:00. W dni robocze wypychasz różne zmiany do kodu. Potok jest uruchamiany 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 wtedy, gdy nie ma żadnych zmian w kodzie, możesz użyć słowa kluczowego always .

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

Klasyczny

Aby skonfigurować zaplanowany potok do kompilacji tylko wtedy, gdy nastąpiła zmiana od ostatniej kompilacji, sprawdź tylko harmonogram kompilacji, jeśli źródło lub potok uległ zmianie.

Limity liczby zaplanowanych przebiegów 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 uruchomień na potok tygodniowo
• 10 uruchomień na potok na 15 minut

Migrowanie z edytora klasycznego

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

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

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

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

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

  

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

  

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 kompilacja dzienna M-F 3:00 (UTC + 5:30) Indie codziennie kompilacja, składnia cron (mm HH DD MM DW) to 30 21 * * Sun-Thu.

• Minuty i godziny — 30 21 to mapuje na 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, aby dotrzeć do żądanej godziny UTC, aby określić dla wyzwalacza YAML.
• 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 kompilacje były uruchamiane o godzinie 3:00 w strefie czasowej UTC + 5:30 Indie, musimy określić rozpoczęcie ich poprzedniego dnia w czasie UTC. Możemy również określić dni tygodnia jako 0-4 lub 0,1,2,3,4.

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

• Minuty i godziny — 0 8 to mapuje na 8:00 AM UTC. Ponieważ określona strefa czasowa w edytorze klasycznym to UTC - 5:00, musimy dodać 5 godzin od żądanego czasu kompilacji 3:00, aby dotrzeć do żądanej godziny UTC, aby określić dla wyzwalacza YAML.
• 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 — Mon-Fri ponieważ nasze konwersje strefy czasowej nie obejmują wielu dni tygodnia dla żądanego harmonogramu, nie musimy wykonywać żadnej konwersji w tym miejscu. 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.

Napiwek

W przypadku używania 3-literowych dni tygodnia i chcienia zakresu wielu dni przez Słońce, Sun należy uznać za pierwszy dzień tygodnia, np. Dla harmonogramu północy EST, czwartek 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, gałęzie kompilacji spełniające kryteria filtrowania main gałęzi i releases/*

  

• Co niedzielę o 3:00 czasu UTC skompiluj releases/lastversion gałąź, nawet jeśli źródło lub potok nie uległ zmianie

  

Odpowiedni wyzwalacz zaplanowany YAML to:

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 3:00 (UTC) wynosi 0 3 * * Mon-Fri.

• Minuty i godziny — 0 3 to mapuje na 3:00 AM UTC. Ponieważ określona strefa czasowa w edytorze klasycznym to UTC, nie musimy wykonywać żadnych konwersji strefy czasowej.
• 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 — Mon-Fri ponieważ nie ma konwersji strefy czasowej, dni tygodnia mapy bezpośrednio z harmonogramu edytora klasycznego. Możemy również określić dni tygodnia jako 1,2,3,4,5.

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

• Minuty i godziny — 0 3 to mapuje na 3:00 AM UTC. Ponieważ określona strefa czasowa w edytorze klasycznym to UTC, nie musimy wykonywać żadnych konwersji strefy czasowej.
• 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 ponieważ nasze konwersje strefy czasowej nie obejmują wielu dni tygodnia dla żądanego harmonogramu, nie musimy wykonywać żadnej konwersji w tym miejscu. Możemy również określić dni tygodnia jako 0.
• Określamy always: true również, że ta kompilacja ma być uruchamiana, czy kod źródłowy został zaktualizowany.

Często zadawane pytania

• Chcę, aby mój potok był uruchamiany tylko zgodnie z harmonogramem, a nie wtedy, gdy ktoś wypchnie zmianę 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 mogę 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 drugiej. Jak mogę to naprawić?

Chcę, aby mój potok był uruchamiany tylko zgodnie z harmonogramem, a nie wtedy, gdy ktoś wypchnie zmianę do gałęzi

Jeśli chcesz, aby potok był uruchamiany tylko zgodnie z harmonogramem, a nie wtedy, gdy ktoś wypchnie zmianę do gałęzi lub scali zmianę w gałęzi głównej, musisz jawnie wyłączyć domyślne wyzwalacze ciągłej integracji i żądania ściągnięcia w potoku.

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

trigger: none
pr: none

Aby uzyskać więcej informacji, zobacz definicję żądania ściągnięcia i definicję wyzwalacza.

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

• 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. Lista jest filtrowana, aby pokazać tylko nadchodzące kilka przebiegów w ciągu najbliższych kilku 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 interfejsu użytkownika, przechodząc do edytora potoku, a następnie wybierając pozycję 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ć to zachowanie.

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

• Jeśli nie określono always:trueparametru , potok nie zostanie zaplanowany, chyba że w kodzie zostaną wprowadzone żadne aktualizacje. Sprawdź, czy nastąpiły jakieś zmiany w kodzie i jak skonfigurowano harmonogramy.

• Istnieje limit liczby zaplanowanych potoków. Sprawdź, czy przekroczono te limity.

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

• Sprawdź, czy potok jest wstrzymany lub wyłączony. Wybierz Ustawienia dla potoku.

• 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 przebieg ręcznie.

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

• Być może włączono opcję, aby 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 ta opcja została zaznaczona w zaplanowanych wyzwalaczach.

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

• Być może połączenie usługi zostało zaktualizowane w celu nawiązania połą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, zostanie utworzony przebieg informacyjny. Jest to fikcyjna kompilacja, która poinformuje Cię, że usługa Azure Pipelines nie może nawiązać połączenia z repozytorium.

• Potok może nie mieć całkowicie pomyślnej kompilacji. 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ę planowany przebieg w panelu Zaplanowane uruchomienia. Jednak nie jest ona uruchamiana w tym czasie. Dlaczego?

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

Harmonogramy zdefiniowane w potoku YAML działają dla jednej gałęzi, ale nie drugiej. Jak mogę 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, powiedzmy features/X, upewnij się, że plik YAML w tej gałęzi ma zdefiniowany harmonogram cron i że ma poprawne dołączania gałęzi dla harmonogramu. Plik YAML w features/X gałęzi powinien mieć następujące elementy 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 zaplanowanych wyzwalaczy.