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

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

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

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

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

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

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

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

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

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

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

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