Настройка расписаний для конвейеров

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

Azure Pipelines предоставляет несколько типов триггеров для настройки запуска конвейера.

• Запланированные триггеры запускают конвейер по расписанию, например, для ночных сборок. В этой статье даются рекомендации по применению запланированных триггеров для запуска конвейеров по расписанию.
• Триггеры на основе событий запускают ваш конвейер в ответ на события, такие как создание pull request или отправка в ветку. Сведения об использовании триггеров на основе событий см. в разделе Триггеры в Azure Pipelines.

Вы можете объединить запланированные и основанные на событиях триггеры в ваших потоках, например, для проверки сборки каждый раз, когда выполняется отправка (триггер CI), когда создается запрос на слияние (триггер PR), а также для ночной сборки (запланированный триггер). Если вы хотите запускать ваш конвейер только по расписанию, а не в ответ на триггеры событий, убедитесь, что в вашем конвейере не включены другие триггеры. Например, конвейеры YAML в репозитории GitHub имеют триггеры CI и триггеры PR, включенные по умолчанию. Сведения об отключении триггеров по умолчанию см. в разделе Триггеры в Azure Pipelines и перейдите к разделу, посвященному типу репозитория.

Запланированные триггеры

YAML

Важный

Запланированные триггеры, определенные с помощью пользовательского интерфейса параметров конвейера, имеют приоритет над запланированными триггерами YAML.

Если конвейер YAML содержит как запланированные триггеры YAML, так и определяемые пользовательским интерфейсом триггеры, выполняются только определенные запланированные триггеры пользовательского интерфейса. Чтобы запустить определенные запланированные триггеры YAML в конвейере YAML, необходимо удалить запланированные триггеры, определенные в пользовательском интерфейсе параметров конвейера. После удаления всех запланированных триггеров пользовательского интерфейса необходимо выполнить отправку для запуска оценки запланированных триггеров YAML.

Сведения о том, как удалить триггеры, запланированные в пользовательском интерфейсе из конвейера YAML, см. раздел параметры пользовательского интерфейса отменяют запланированные триггеры YAML.

Запланированные триггеры настраивают конвейер для выполнения по расписанию, определенному с помощью синтаксиса 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

Запланированные конвейеры в YAML имеют следующие ограничения.

• Часовой пояс для расписаний cron — UTC. Вы можете получить помощь по искусственному интеллекту от GitHub Copilot для создания выражений cron.
• Если указать предложение exclude без предложения include для branches, это эквивалентно указанию * в предложении include.
• Нельзя использовать переменные конвейера при указании расписаний.
• Если вы используете шаблоны в файле YAML, то расписания должны быть указаны в основном файле YAML, а не в файлах шаблонов.

Рекомендации по выбору ветвей для запланированных триггеров

Запланированные триггеры вычисляются для ветви при возникновении следующих событий.

• Создается конвейер.
• Файл YAML конвейера обновляется при выполнении push или при редактировании в редакторе YAML конвейера.
• Путь к файлу YAML конвейера обновлен для указания на другой файл YAML. Данное изменение обновляет только основную ветвь, поэтому учитываются только расписания из обновленного файла YAML для основной ветви. Если любые другие ветви впоследствии объединяют ветвь по умолчанию, например git pull origin main, запланированные триггеры из вновь указанного YAML-файла оцениваются для этой ветви.
• Создается новая ветвь.

После того как одно из этих событий происходит в ветви, добавляются все запланированные запуски для этой ветви, если эта ветвь соответствует фильтрам ветви для запланированных триггеров, содержащихся в ФАЙЛЕ YAML в этой ветви.

Важный

Запланированные запуски для ветви добавляются только в том случае, если ветвь совпадает с фильтрами ветви в запланированных триггерах в файле YAML в данной конкретной ветви.

Например, конвейер создается со следующим расписанием, и эта версия ФАЙЛА YAML проверяется в ветви main. Этот график ежедневно создает ветвь main.

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

Затем создается новая ветвь на основе mainс именем new-feature. Запланированные триггеры из YAML-файла в новой ветке считываются, и поскольку для ветки new-feature совпадений нет, изменения в запланированных сборках не вносятся, а ветка new-feature не строится с использованием запланированного триггера.

Если new-feature добавляется в список branches и это изменение отправляется в ветвь new-feature, файл YAML считывается, и так как new-feature теперь находится в списке ветвей, запланированная сборка добавляется для ветви new-feature.

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

Теперь рассмотрим, что ветвь с именем release создается на основе main, а затем release добавляется в фильтры ветвей в файле YAML в ветви main, но не в созданной ветви 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

Поскольку release был добавлен в фильтры ветки main, но не был добавлен к фильтрам ветки release наряду с, ветка release не будет создана по этому расписанию. Только когда ветка release будет добавлена в фильтры веток файла YAML в релизной ветке, запланированная сборка будет добавлена в планировщик.

Рекомендации по пакетной обработке для запланированных триггеров

Свойство batch настраивает, следует ли запускать конвейер, если ранее запланированное выполнение выполняется. Если batchtrue, новый запуск конвейера не начнется по расписанию, если предыдущий запуск всё ещё выполняется. Значение по умолчанию — false.

Свойство batch зависит от параметра свойства always. Если alwaystrue, запуск производится в соответствии с расписанием cron, даже когда batchtrue и запущен процесс.

Всегда	Партия	Поведение
false	false	Конвейер выполняется только в том случае, если есть изменение относительно последнего успешного запланированного запуска конвейера, даже если выполняется запуск от последнего запланированного триггера.
false	true	Конвейер выполняется только в том случае, если происходит изменение относительно последнего успешного запланированного выполнения конвейера, и не выполняется запланированное выполнение конвейера.
true	false	Пайплайн выполняется в соответствии с расписанием cron.
true	true	Конвейер проводится в соответствии с расписанием cron, даже если запуск в процессе.

Переменная Build.CronSchedule.DisplayName

При выполнении конвейера вследствие запланированного триггера cron предопределенная переменная Build.CronSchedule.DisplayName содержит displayName расписания cron, инициирует запуск конвейера.

Конвейер YAML может содержать несколько расписаний cron, и может потребоваться, чтобы конвейер выполнял различные этапы или задания на основе которых выполняется расписание cron. Например, у вас есть ночная сборка и еженедельная сборка, и вы хотите запустить определенный этап только во время ночной сборки. Можно использовать переменную Build.CronSchedule.DisplayName в задании или условии этапа, чтобы определить, следует ли выполнять это задание или этап.

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

Больше примеров смотрите в примерах schedules.cron.

классические

Выберите дни и время выполнения сборки с помощью классического редактора.

Если репозиторий — Azure Repos Git, GitHub или Other Git, можно также указать ветви для включения и исключения. Если вы хотите использовать подстановочные знаки, введите спецификацию ветви (например, features/modules/*) и нажмите клавишу ВВОД.

Примеры

YAML

В следующем примере определяются два расписания:

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

Первое расписание, ежедневной сборки в полночь, выполняет конвейер в полночь каждый день, но только если код изменился с момента последнего успешного запланированного выполнения, для main и всех releases/* веток, кроме веток под releases/ancient/*.

Второй график, Еженедельная воскресная сборка, запускает конвейер в полдень в воскресенье, вне зависимости от того, изменился ли код с момента последнего запуска, для всех releases/* ветвей.

Заметка

Часовой пояс для расписаний cron — UTC, поэтому в этих примерах полночная сборка осуществляется в полночь, а сборка в полдень осуществляется в полдень по UTC.

Дополнительные примеры см. в Миграция из классического редактора.

классика

Пример: ночная сборка репозитория Git в нескольких часовых поясах

В этом примере в классическом редакторе запланированный триггер содержит две записи, которые создают следующие сборки.

• Каждый день с понедельника по пятницу в 3:00 (UTC + 5:30) собирайте ветки, которые соответствуют критериям фильтра features/india/*.

  

• Каждый понедельник по пятницу в 3:00 утра (в часовом поясе UTC - 5:00) выполняйте сборку веток, соответствующих критериям фильтра веток features/nc/*.

  

Пример: ночная сборка с разными частотами

Azure Pipelines и Azure DevOps 2019 Server

В этом примере в классическом редакторе триггер расписания содержит две записи, которые запускают следующие сборки.

• С понедельника по пятницу в 3:00 утра по UTC выполняется сборка ветвей, которые соответствуют критериям фильтра ветви main и releases/*.

  

• Каждое воскресенье в 3:00 UTC создайте ветвь releases/lastversion, даже если источник или конвейер не изменился.

  

Синтаксис Cron

YAML

Каждое запланированное выражение триггера cron в Azure Pipelines — это выражение с разделителями пространства с пятью записями в следующем порядке. Выражение заключено в одинарные кавычки '.

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

Поле	Принятые значения
Минуты	От 0 до 59
Часов	От 0 до 23
Дни	1–31
Месяцы	1–12, полные английские имена, первые три буквы английских имен
Дни недели	От 0 до 6 (начиная с воскресенья), полные английские имена, первые три буквы английских имен

Значения могут находиться в следующих форматах.

Формат	Пример	Описание
Подстановочный знак	*	Соответствует всем значениям этого поля
Одно значение	5	Указывает одно значение для этого поля
Разделённый запятыми	3,5,6	Задает несколько значений для этого поля. Можно объединить несколько форматов, например 1,3-6
Диапазоны	1-3	Инклюзивный диапазон значений для этого поля
Интервалы	*/4 или 1-5/2	Интервалы, соответствующие этому полю, например каждое четвертое значение или диапазон 1–5 с интервалом шага 2

Пример	Выражение Cron
Сборка каждый понедельник, среду и пятницу в 18:00.	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5или 0 18 * * 1-5/2
Сборка осуществляется каждые 6 часов	0 0,6,12,18 * * *, 0 */6 * * * или 0 0-18/6 * * *
Сборка каждые 6 часов, начиная с 9:00 утра	0 9,15,21 * * * или 0 9-21/6 * * *

Дополнительные сведения о поддерживаемых форматах см. в crontab Expression.

Создание выражения cron с помощью GitHub Copilot

Вы можете получить помощь по искусственному интеллекту от GitHub Copilot для создания выражений cron или преобразовать существующие выражения cron из локального часового пояса в UTC.

Расписания cron в Azure Pipelines определяются в формате всемирного координированного времени (UTC), поэтому расписания, такие как сборка каждый понедельник, среду и пятницу в 6:00 вечера, должны быть созданы с помощью синтаксиса cron и преобразованы из локального часового пояса в UTC.

Настройте следующие подсказки для создания выражений cron или преобразования этих выражений в UTC из часового пояса, в котором они были созданы.

В следующем примере Copilot будет предложено установить расписание cron для UTC, чтобы выполнять сборку каждого понедельника, среды и пятницы в 18:00 по Восточному стандартному времени.

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

Если у вас уже есть выражение cron в местном часовом поясе, можно попросить Copilot преобразовать его в формате UTC. В этом примере расписание cron для выполнения задачи каждый понедельник, среду и пятницу в 18:00 (0 18 * * Mon,Wed,Fri) по Восточному стандартному времени преобразуется в UTC.

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

Преобразование выражения cron в UTC может потребовать изменения дней недели в выражении. В следующем примере Copilot будет предложено создать расписание UTC cron, чтобы выполнять задачи с понедельника по пятницу в 12:30 по центральноевропейскому стандартному времени. Центральное европейское стандартное время впереди UTC, поэтому результирующее выражение начинается поздно вечером в воскресенье, а не рано утром в понедельник, и заканчивается в четверг.

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

Чтобы получить дополнительные сведения о выражении cron, созданном Copilot, можно попросить Copilot предоставить объяснение созданного выражения cron в запросе.

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 работает на ИИ, поэтому возможны сюрпризы и ошибки. Подробности см. в Общие вопросы об использовании Copilot.

Классические

Классические расписания определяются с помощью графического редактора вместо синтаксиса cron. Подробную информацию об определении классических графиков см. в примерах.

Просмотр запланированных запусков

YAML

Вы можете просмотреть предпосмотр предстоящих запланированных сборок, выбрав запланированные сборки из контекстного меню на странице деталей вашего конвейера.

Важный

В представлении запланированных запусков отображаются лишь те конвейеры, которые запланированы на выполнение в течение семи дней, начиная с текущей даты. Если расписание cron имеет интервал более 7 дней, а следующий запуск планируется начать через семь дней с текущей даты, он не будет отображаться в представлении запланированных запусков.

После создания или обновления запланированных триггеров их можно проверить в представлении запланированных запусков.

В этом примере отображаются запланированные запуски для следующего расписания.

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

запланированные запуски окна отображают время, преобразованное в локальный часовой пояс на компьютере, используемом для перехода на портал Azure DevOps. В этом примере показан снимок экрана, сделанный в часовом поясе EST.

Заметка

Если вы обновите расписание для работающего конвейера, представление 'Запланированные запуски' не обновляется с новым расписанием до завершения выполнения конвейера.

классические

Вы можете просмотреть предстоящие запланированные сборки, выбрав запланированные запуски из контекстного меню на странице информации о вашем конвейере .

После создания или обновления запланированных триггеров их можно проверить с помощью этого представления.

Выполнение даже при отсутствии изменений в коде

По умолчанию ваш конвейер не выполняется по расписанию, если с момента последнего успешного запланированного выполнения не было изменений в коде. Например, предположим, что вы запланировали запуск конвейера каждую ночь в 9:00 вечера. В рабочие дни вы отправляете различные изменения в ваш код. Процесс идёт по расписанию. В выходные дни вы не вносите никаких изменений в код. Если после запланированного выполнения в пятницу не было изменений в коде, то конвейер не выполняется по расписанию в выходные дни.

YAML

Чтобы принудительно запустить конвейер даже при отсутствии изменений кода, можно использовать ключевое слово always.

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

классические

Чтобы настроить запланированный конвейер для сборки только в том случае, если с момента последней сборки произошло изменение, отметьте Запускать запланированные сборки только при изменении источника или конвейера.

Ограничения на количество запланированных запусков в конвейерах YAML

Существуют определенные ограничения на то, как часто можно запланировать выполнение конвейера. Эти ограничения были установлены для предотвращения неправильного использования ресурсов Azure Pipelines, особенно размещенных корпорацией Майкрософт агентов. Ограничения:

• около 1000 запусков на конвейер в неделю
• 10 запусков на конвейер за 15 минут

Миграция из классического редактора

В следующих примерах показано, как перенести расписания из классического редактора в YAML.

• пример. Ночная сборка репозитория Git в нескольких часовых поясах
• Пример: ночная сборка с разными частотами

Пример: ночная сборка репозитория Git в нескольких часовых поясах

В этом примере для классического редактора запланированный триггер содержит две записи, создающие следующие сборки.

• С понедельника по пятницу в 3:00 утра (в часовом поясе UTC + 5:30) выполняются сборки веток, соответствующие критериям фильтрации веток features/india/*.

  

• С понедельника по пятницу в 3:00 утра (UTC − 5:00), собирайте ветки, которые соответствуют критериям фильтрации веток features/nc/*.

  

Эквивалентный запланированный триггер YAML:

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

В первом расписании M-F 3:00 (UTC + 5:30) Индия, ежедневная сборка, синтаксис cron (mm HH DD MM DW) 30 21 * * Sun-Thu.

• Минуты и часы — 30 21 — это сопоставляется с 21:30 UTC (9:30 PM UTC). Поскольку указанный часовой пояс в классическом редакторе UTC + 5:30, необходимо вычесть 5 часов и 30 минут из времени сборки 3:00 утра, чтобы получить нужное время UTC для указания в триггере YAML. Вы можете получить помощь с использованием искусственного интеллекта от GitHub Copilot, чтобы создатьcron-выражение.
• Дни и месяцы указаны в качестве подстановочных символов, так как в этом расписании не предусмотрено выполнение только в определенные дни месяца или в определенном месяце.
• Дни недели - Sun-Thu - из-за преобразования часового пояса, чтобы наши сборки выполнялись в 3:00 в часовом поясе Индии с UTC + 5:30, необходимо указать их начало с предыдущего дня по времени UTC. Мы также можем указать дни недели как 0-4 или 0,1,2,3,4.

Во втором расписании Пн-Пт 3:00 утра (UTC - 5) ежедневной сборки NC, синтаксис cron 0 8 * * Mon-Fri.

• Минуты и часы — 0 8 — соотносится с 8:00 AM UTC. Поскольку указанный часовой пояс в классическом редакторе UTC - 5:00, необходимо добавить 5 часов к требуемому времени сборки в 3:00, чтобы рассчитать нужное время по UTC для триггера YAML. С помощью GitHub Copilot вы можете получить помощь со стороны искусственного интеллекта для созданиявыражения cron.
• Дни и месяцы указываются как подстановочные знаки, поскольку это расписание не предусматривает запуск только в определенные дни месяца или в определенный месяц.
• Дни недели - Mon-Fri - Потому что наши преобразования часовых поясов не охватывают несколько дней недели для нашего желаемого расписания, мы не должны делать никаких преобразований здесь. Мы также можем указать дни недели как 1-5 или 1,2,3,4,5.

Важный

В часовых поясах UTC в запланированных триггерах YAML не учитывается переход на летнее время.

Совет

При использовании трехбуквенных обозначений дней недели и при необходимости охватить несколько дней до воскресенья, воскресенье следует считать первым днем недели, например, для расписания, начинающегося с полуночи EST, с четверга по воскресенье, синтаксис cron - 0 5 * * Sun,Thu-Sat.

Пример: ночная сборка с разными частотами

В этом примере планируемый триггер классического редактора содержит две записи, создающие следующие сборки.

• Каждый день с понедельника по пятницу в 3:00 UTC производится сборка ветвей, которые соответствуют критериям фильтра ветвей main и releases/*.

  

• Каждое воскресенье в 3:00 по координатному времени UTC собирайте ветвь releases/lastversion, даже если источник или конвейер не изменился.

  

Эквивалентный запланированный триггер YAML:

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

В первом расписании M-F в 3:00 ночи (UTC) для ежедневной сборкисинтаксис cron — 0 3 * * Mon-Fri.

• Минуты и часы — 0 3 — это соответствует 3:00 AM UTC. Так как указанный часовой пояс в классическом редакторе UTC, нам не нужно выполнять преобразования часовых поясов.
• Дни и месяцы указываются как подстановочные знаки, так как это расписание не указывает, чтобы выполняться только в определенные дни месяца или в определенном месяце.
• Дни недели - Mon-Fri - потому что нет преобразования часового пояса, дни недели переносятся непосредственно из классического редакторского расписания. Мы также можем указать дни недели как 1,2,3,4,5.

Во втором расписании воскресенье 3:00 (UTC) еженедельная сборка последней версии, синтаксис cron 0 3 * * Sun.

• Минуты и часы — 0 3 — это сопоставляется с 3:00 AM UTC. Так как указанный часовой пояс в классическом редакторе UTC, нам не нужно выполнять преобразования часовых поясов.
• Дни и месяцы указываются как подстановочные знаки, так как это расписание не указывает, чтобы выполняться только в определенные дни месяца или в определенном месяце.
• Дни недели - Sun - Потому что наши преобразования часовых поясов не охватывают несколько дней недели для нашего желаемого расписания, мы не должны делать никаких преобразований здесь. Мы также можем указать дни недели как 0.
• Кроме того, мы указываем always: true, так как эта сборка планируется запустить независимо от того, был ли обновлен исходный код.

Вопросы и ответы

• я хочу, чтобы конвейер запускался только по расписанию, а не когда кто-то отправляет изменения в ветвь
• Я определил расписание в ФАЙЛЕ YAML. Но оно не работало. Что случилось?
• Мои расписания YAML работали нормально. Но, они перестали работать сейчас. Как выполнить отладку?
• Мой код не изменился, но запускается запланированная сборка. Почему?
• Я вижу запланированное выполнение на панели запланированных запусков. Однако он не выполняется в этот момент. Почему?
• Расписания, определенные в конвейере YAML, работают для одной ветви, но не для другой. Как исправить это?

Я хочу, чтобы конвейер запускался только по расписанию, а не когда кто-то вносит изменения в ветку.

Если вы хотите, чтобы ваш пакет выполнялся только по расписанию, а не когда кто-то отправляет изменение в ветвь или объединяет изменение в основную ветвь, необходимо явно отключить триггеры CI и PR по умолчанию в пакете.

Чтобы отключить триггеры CI и PR по умолчанию, добавьте следующие инструкции в конвейер YAML и убедитесь, что триггеры конвейера YAML переопределены с помощью триггеров пользовательского интерфейса.

trigger: none
pr: none

Для получения дополнительной информации см. определение и определение триггера .

Я определил расписание в ФАЙЛЕ YAML. Но это не запустилось. Что случилось?

• Проверьте, какие запуски Azure Pipelines были запланированы для вашего конвейера на ближайшее время. В вашем конвейере можно найти эти запуски, выбрав действие запланированные задания. Список отфильтрован, чтобы показать только предстоящие несколько запусков в течение следующих нескольких дней. Если это не соответствует вашим ожиданиям, это, вероятно, случай, когда вы неправильно ввели расписание cron, или у вас нет расписания, определенного в правильной ветви. Ознакомьтесь с приведенным выше разделом, чтобы понять, как настроить расписания. Переоценьте синтаксис cron. Всё время расписаний cron указано по времени UTC.

• Внесите небольшое тривиальное изменение в файл YAML и отправьте это обновление в репозиторий. Если возникла проблема с чтением расписаний из ФАЙЛА YAML ранее, она должна быть исправлена.

• Если в пользовательском интерфейсе определены какие-либо расписания, ваши расписания YAML не учитываются. Убедитесь, что у вас нет расписания в интерфейсе, перейдя в редактор вашего конвейера, затем выберите Триггеры.

• Существует ограничение на количество запусков, которые можно запланировать для конвейера. Узнайте больше об ограничениях .

• Если в вашем коде нет изменений, Azure Pipelines могут не начинать новые выполнения. Узнайте, как переопределить это поведение.

Мои расписания YAML работали нормально. Но, они перестали работать сейчас. Как выполнить отладку?

• Если вы не указали always:true, ваш поток не будет запланирован, если в ваш код не внесены обновления. Проверьте, были ли изменения кода и как вы настроили расписания.

• Существует ограничение на количество раз, сколько можно запланировать ваш поток. Проверьте, превысили ли вы эти ограничения.

• Проверьте, включил ли кто-то больше расписаний в пользовательском интерфейсе. Откройте редактор вашего конвейера и выберите триггеры. Если они определили расписания в пользовательском интерфейсе, ваши расписания YAML не будут учитываться.

• Проверьте, приостановлен или отключен ли конвейер. Выберите параметры для конвейера.

• Проверьте следующие несколько запусков, запланированных для конвейера Azure Pipelines. Эти запуски можно найти, выбрав Запланированные запуски в вашем плане. Если вы не видите ожидаемые расписания, сделайте небольшое тривиальное изменение файла YAML и отправьте обновление в репозиторий. Это должно повторно синхронизировать расписания.

• Если вы используете GitHub для хранения кода, возможно, что Azure Pipelines могли быть ограничены GitHub при попытке начать новый прогон. Проверьте, можно ли запустить новый запуск вручную.

Мой код не изменился, но запускается запланированная сборка. Почему?

• Возможно, вы включили возможность всегда запускать запланированную сборку, даже если изменения кода отсутствуют. Если вы используете YAML-файл, проверьте синтаксис расписания в YAML-файле. Если вы используете классические конвейеры, проверьте, установлен ли этот параметр в запланированных триггерах.

• Возможно, вы обновили конвейер сборки или некоторые свойства конвейера. Это приведет к планированию нового запуска, даже если вы не обновили исходный код. Проверьте журнал изменений в конвейере с помощью классического редактора.

• Возможно, вы обновили подключение службы, используемое для подключения к репозиторию. Это приведет к планированию нового запуска, даже если вы не обновили исходный код.

• Azure Pipelines сначала проверяет наличие обновлений кода. Если Azure Pipelines не может связаться с репозиторием или получить эти сведения, он создаст информационный запуск. Это фиктивная сборка, чтобы сообщить вам, что Azure Pipelines не может получить доступ к репозиторию.

• Возможно, у конвейера нет полностью успешной сборки. Чтобы определить, следует ли запланировать новую сборку или нет, Azure DevOps ищет последнюю полностью успешную запланированную сборку. Если он не находит его, он активирует новую запланированную сборку. Частично успешные запланированные сборки не считаются успешными, поэтому если конвейер имеет только частично успешные сборки, Azure DevOps активирует запланированные сборки, даже если код не изменился.

Я вижу запланированное выполнение на панели запланированных запусков. Однако он не запускается в это время. Почему?

• На панели "Запланированные запуски" отображаются все потенциальные расписания. Тем не менее, он может не выполняться, если вы не внесли действительные изменения в код. Чтобы принудительно выполнять расписание, убедитесь, что вы установили свойство всегда в конвейере YAML или выбрали параметр для всегда выполнения в классическом конвейере.

Расписания, определенные в конвейере YAML, работают для одной ветви, но не для другой. Как исправить это?

Расписания определяются в файлах YAML, и эти файлы связаны с ветвями. Если вы хотите, чтобы конвейер был запланирован для конкретной ветки, например, features/X, убедитесь, что файл YAML в этой ветке содержит определенное в нем расписание cron и правильные включения веток для этого расписания. Файл YAML в ветви features/X должен иметь следующие schedule в этом примере:

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

Дополнительные сведения см. в статье Вопросы о запланированных триггерах.