запланированные сборки никогда не запускаются в конвейере Azure Devops

Question

У меня есть следующая конфигурация в моем проекте с открытым исходным кодом, размещенном на GitHub: https://github.com/wez/wezterm/blob/master/azure-pipelines.yml#L9

schedules:
- cron: "0 0 * * *"
  displayName: Daily build
  always: true
  branches:
    include:
- master

моя лазурная организация - https://dev.azure.com/wez0788/wezterm. Мой проект с открытым исходным кодом и использует бесплатный уровень.

Расписание не оказывает никакого влияния; в списке сборок не отображается запланированная сборка.

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

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

У кого-то, похоже, возникла та же проблема, и он подал здесь проблему GH, но, поскольку это был механизм отслеживания проблем с документами, он был закрыт: https://github.com/MicrosoftDocs/vsts-docs/issues/4589

Как я могу запустить запланированную сборку?

Answer 1

Автор только что предоставил метод, который, я думаю, мог бы вам помочь. Когда вы впервые начнете строить свой конвейер с помощью github repo, он не будет запускать запуск по расписанию. Вам нужно изменить файл yaml. После модификации сборка расписания должна запускаться нормально.

Второй сценарий: есть два участника, которые все используют репо на одном и том же github для построения конвейера. Конвейер сборки одного участника не может запустить сборку расписания, а другой участник может нормально запустить сборку расписания. Их решение заключается в следующем: в конвейере, который может инициировать построение расписания, снова запустите построение расписания. В это время конвейер, который не может запустить сборку по расписанию, также показывает эту текущую сборку по расписанию. После этого он может нормально запускать график сборки. Поэтому я предлагаю вам попытаться построить конвейер с тем же репозиторием github в другом проекте или организации. Если pipelien может нормально запустить сборку расписания, то вы можете использовать мой метод для восстановления конвейера, который не может запустить сборку расписания.

Кроме того, я думаю, что ваш оператор yaml не проблема, я протестировал его с тем же оператором, он может нормально запускать построение расписания.

Я полагаю, что вы можете установить более короткое время запуска, что удобно для тестирования. Например: Этот параметр запускает построение расписания каждую минуту.

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

Надеюсь, это поможет.

Answer 2

Попробуйте использовать следующее, просто замените двойную кавычку "на одинарную кавычку"

schedules:
- cron: '0 0 * * *'
  displayName: Daily build
  branches:
    include:
    - master
  always: true