Поделиться через

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

  • Статья

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

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

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

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

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

Внимание

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

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.
  • Если указать exclude предложение без include предложения branches, это эквивалентно указанию * в предложении include .
  • Нельзя использовать переменные конвейера при указании расписаний.
  • Если вы используете шаблоны в ФАЙЛЕ YAML, расписания должны быть указаны в основном файле YAML, а не в файлах шаблона.

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

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

  • Создается конвейер.
  • Файл 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 свойство доступно в Azure DevOps Server 2022.1 и выше.

Свойство batch настраивает, следует ли запускать конвейер, если ранее запланированное выполнение выполняется; значение по умолчанию false. Это не зависит от версии репозитория конвейера.

В следующей таблице описывается, как always и batch взаимодействовать.

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

Внимание

Когда always это trueтак, конвейер выполняется в соответствии с расписанием cron, даже если batch есть true.

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

Примечание.

Переменная Build.CronSchedule.DisplayName доступна в Azure DevOps Server 2022.1 и выше.

Когда конвейер выполняется из-за запланированного триггера 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.

Запланированные сборки не поддерживаются в синтаксисе YAML в Azure DevOps Server 2019. После создания конвейера сборки 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.

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

Запланированные сборки не поддерживаются в синтаксисе YAML в Azure DevOps Server 2019. После создания конвейера сборки YAML можно использовать параметры конвейера для указания запланированного триггера.

Синтаксис Cron

Каждое запланированное выражение триггера 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 (начиная с воскресенья), полные английские имена, первые три буквы английских имен

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

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

Запланированные сборки не поддерживаются в синтаксисе YAML в Azure DevOps Server 2019. После создания конвейера сборки YAML можно использовать параметры конвейера для указания запланированного триггера.

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

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

Внимание

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

Меню запланированных запусков

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

Запланированные запуски

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

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

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

Примечание.

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

Запланированные сборки не поддерживаются в синтаксисе YAML в Azure DevOps Server 2019. После создания конвейера сборки YAML можно использовать параметры конвейера для указания запланированного триггера.

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

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

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

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

Запланированные сборки не поддерживаются в синтаксисе YAML в этой версии Azure DevOps Server. После создания конвейера сборки YAML можно использовать параметры конвейера для указания запланированного триггера.

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

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

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

Перенос из классического редактора

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

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

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

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

    Запланированный триггер UTC + 5:30 часовой пояс

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

    Запланированный триггер UTC -5:00 часовой пояс

Эквивалентный запланированный триггер 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.
  • Дни и месяцы указываются как дикие карта поскольку это расписание не указывает, чтобы выполняться только в определенные дни месяца или в определенном месяце.
  • Дни недели - Sun-Thu из-за преобразования часового пояса, для наших сборок, которые будут выполняться в 3:00 в формате UTC + 5:30 Индия часовой пояс, необходимо указать, начиная с предыдущего дня в формате UTC. Мы также можем указать дни недели как 0-4 или 0,1,2,3,4.

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

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

Внимание

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

Совет

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

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

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

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

    Частота запланированного триггера 1.

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

    Частота запланированного триггера 2.

Эквивалентный запланированный триггер 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) используется 0 3 * * Mon-Friсинтаксис cron.

  • Минуты и часы — 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 , так как эта сборка планируется запустить независимо от того, был ли обновлен исходный код.

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

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

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

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

trigger: none
pr: none

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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