Configurar agendamentos para pipelines

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

O Azure Pipelines fornece vários tipos de gatilhos para configurar a forma como o pipeline será iniciado.

• Os gatilhos agendados iniciam seu pipeline com base em um agendamento, como um build noturno. Este artigo fornece diretrizes sobre como usar gatilhos agendados para executar seus pipelines com base em um agendamento.
• Os gatilhos baseados em eventos iniciam o pipeline em resposta a eventos, como criar uma solicitação de pull ou enviar para um branch. Para obter informações sobre como usar gatilhos baseados em eventos, confira Gatilhos no Azure Pipelines.

Você pode combinar gatilhos agendados e baseados em eventos nos seus pipelines, por exemplo, para validar o build sempre que um push é feito (gatilho de CI), quando uma solicitação de pull é feita (gatilho de PR) e um build noturno (gatilho agendado). Se você quiser compilar seu pipeline apenas em um agendamento e não em resposta a gatilhos baseados em eventos, verifique se o pipeline não tem outro gatilho habilitado. Por exemplo, pipelines YAML em um Repositório do GitHub têm gatilhos de CI e gatilhos de PR habilitados por padrão. Para obter informações sobre como desabilitar gatilhos padrão, confira Gatilhos no Azure Pipelines e navegue até a seção que abrange o tipo de repositório.

Gatilhos agendados

YAML

Importante

Os gatilhos agendados definidos usando a interface do usuário de configurações de pipeline têm precedência sobre gatilhos agendados do YAML.

Se o pipeline YAML tiver gatilhos de agendamentos YAML e gatilhos de agendamentos definidos pela interface do usuário, apenas os gatilhos de agendamentos definidos pela interface do usuário serão executados. Para executar os gatilhos agendados definidos pelo YAML em seu pipeline YAML, você deve remover os gatilhos agendados definidos na interface do usuário das configurações do pipeline. Depois que todos os gatilhos agendados da interface do usuário forem removidos, um push deverá ser feito para que os gatilhos agendados YAML comecem a ser avaliados.

Para excluir gatilhos agendados da interface do usuário de um pipeline YAML, confira As configurações da interface do usuário substituem os gatilhos agendados do YAML.

Os gatilhos agendados configuram um pipeline para ser executado em um agendamento definido usando a sintaxe 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

Os pipelines agendados no YAML têm as seguintes restrições.

• O fuso horário para agendamentos cron é o UTC.
• Se você especificar uma cláusula exclude sem uma cláusula include para branches, isso será equivalente a especificar * na cláusula include.
• Você não pode usar variáveis de pipeline ao especificar os agendamentos.
• Se você usar modelos no arquivo YAML, os agendamentos deverão ser especificados no arquivo YAML principal e não nos arquivos de modelo.

Considerações sobre branch para gatilhos agendados

Os gatilhos agendados são avaliados para um branch, quando ocorrem os eventos a seguir.

• Um pipeline foi criado.
• O arquivo YAML de um pipeline foi atualizado, seja a partir de um push ou no editor de pipeline.
• O caminho do arquivo YAML de um pipeline foi atualizado para referenciar um arquivo YAML diferente. Essa alteração atualiza apenas o branch padrão e, portanto, seleciona apenas os agendamentos no arquivo YAML atualizado para o branch padrão. Se outros branches mesclarem o branch padrão subsequentemente, por exemplo, git pull origin main, os gatilhos agendados do arquivo YAML recém-referenciado serão avaliados para esse branch.
• Um novo branch foi criado.

Depois que um desses eventos ocorrer em um branch, todas as execuções agendadas para esse branch serão adicionadas, se esse branch corresponder aos filtros de branch para os gatilhos agendados contidos no arquivo YAML nesse branch.

Importante

As execuções agendadas para um branch serão adicionadas somente se o branch corresponder aos filtros de branch para os gatilhos agendados no arquivo YAML nesse branch específico.

Por exemplo, um pipeline foi criado com o agendamento a seguir e essa versão do arquivo YAML será verificada no branch main. Esse agendamento compila o branch main diariamente.

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

Em seguida, um novo branch será criado com base em main, chamado new-feature. Os gatilhos agendados do arquivo YAML no novo branch foram lidos e, como não há correspondência com o branch new-feature, nenhuma alteração será feita nos builds agendados e o branch new-feature não será compilado usando um gatilho agendado.

Se new-feature for adicionado à lista branches e essa alteração for enviada para o branch new-feature, o arquivo YAML será lido e, como new-feature agora está na lista de branches, um build agendado será adicionado ao branch new-feature.

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

Agora considere que um branch chamado release foi criado com base em main e, em seguida, release foi adicionado aos filtros de branch no arquivo YAML no branch main, mas não no branch release recém-criado.

# 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

Como release foi adicionado aos filtros de branch no branch main, mas não aos filtros de branch no branch release, o branch release não será compilado nesse agendamento. Somente quando o branch release for adicionado aos filtros de branch no arquivo YAML no branch de lançamento, o build agendado será adicionado ao agendador.

Considerações sobre lotes para gatilhos agendados

A propriedade batch configura se o pipeline deve ser executado caso a execução previamente agendada esteja em andamento; o padrão é false. Isso ocorrerá independentemente da versão do repositório de pipeline.

A tabela a seguir descreve como interação always e batch.

Sempre	Lote	Comportamento
false	false	O pipeline é executado somente se houver uma alteração em relação à última execução de pipeline agendada bem-sucedida.
false	true	O pipeline é executado somente se houver uma alteração em relação à última execução de pipeline agendada bem-sucedida e não houver nenhuma execução de pipeline agendada em andamento.
true	false	O pipeline é executado de acordo com o agendamento cron.
true	true	O pipeline é executado de acordo com o agendamento cron.

Importante

Quando always é true, o pipeline é executado de acordo com o agendamento cron, mesmo quando batch é true.

Variável Build.CronSchedule.DisplayName

Quando um pipeline está em execução devido a um gatilho agendamento cron, a variável predefinida Build.CronSchedule.DisplayName contém o displayName do agendamento cron que disparou a execução do pipeline.

Seu pipeline yaml pode conter vários agendamentos cron e talvez você queira que seu pipeline execute diferentes estágios ou trabalhos com base em qual agendamento cron é executado. Por exemplo, você tem um build noturno e um build semanal e deseja executar um determinado estágio somente durante o build noturno. Você pode usar a variável Build.CronSchedule.DisplayName em uma condição de trabalho ou estágio para determinar se deve executar esse trabalho ou estágio.

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

Para obter mais exemplos, confira exemplos de schedules.cron.

Clássico

Selecione os dias e horas em que você deseja executar o build usando o editor clássico.

Se o repositório for o Azure Repos Git, GitHub ou Outro Git, você também pode especificar os branches a serem incluídos e excluídos. Se você quiser usar caracteres curinga, digite a especificação de ramificação (por exemplo, features/modules/*) e pressione Enter.

Exemplos

YAML

O exemplo a seguir define dois agendamentos:

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

O primeiro agendamento, build diário à meia-noite, executa um pipeline à meia-noite todos os dias, somente se o código tiver sido alterado desde a última execução agendada bem-sucedida, para main e todos os branches releases/*, exceto os branches em releases/ancient/*.

O segundo agendamento, build semanal aos domingos, executa um pipeline ao meio-dia aos domingos, independentemente de o código ter sido alterado desde a última execução para todos os branches releases/*.

Observação

O fuso horário para agendamentos cron é o UTC. Portanto, nestes exemplos, o build à meia-noite e o build ao meio-dia ocorrem à meia-noite e ao meio-dia no UTC.

Para obter mais exemplos, confira Como migrar do editor clássico.

Clássico

Exemplo: build noturno do Repositório do Git em vários fusos horários

Neste exemplo, o gatilho agendado do editor clássico tem duas entradas, que produzem os builds a seguir.

• Todas as segundas a sextas-feiras às 3h (fuso horário UTC + 5h30), compile branches que atendam aos critérios do filtro de branch features/india/*

  

• Todas as segundas a sextas-feiras às 3h (fuso horário UTC – 5h), compile branches que atendam aos critérios do filtro de branch features/nc/*

  

Exemplo: build noturno com frequências diferentes

Azure Pipelines e Azure DevOps 2019 Server

Neste exemplo, o gatilho agendado do editor clássico tem duas entradas, que produzem os builds a seguir.

• Todas as segundas a sextas-feiras às 3h UTC, compile branches que atendam aos critérios do filtro de branch main e releases/*

  

• Todos os domingos às 3h UTC, compile o branch releases/lastversion, mesmo que a origem ou o pipeline não tenha sido alterado

  

Sintaxe cron

YAML

Cada expressão cron de gatilho agendado do Azure Pipelines é uma expressão delimitada por espaço com cinco entradas na ordem a seguir. A expressão é colocada entre aspas simples '.

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

Campo	Valores aceitos
minutos	0 a 59
Horas	0 a 23
Dias	1 a 31
Months	1 a 12, nomes completos em inglês, as três primeiras letras dos nomes em inglês
Dias da semana	0 a 6 (começando com domingo), nomes completos em inglês, as três primeiras letras dos nomes em inglês

Os valores podem estar nos seguintes formatos.

Formato	Exemplo	Descrição
Curinga	*	Corresponde a todos os valores para esse campo
Um único valor	5	Especifica um único valor para esse campo
Delimitado por vírgula	3,5,6	Especifica vários valores para esse campo. Vários formatos podem ser combinados, como 1,3-6
Intervalos	1-3	O intervalo inclusivo de valores para esse campo
Intervalos	*/4 ou 1-5/2	Intervalos para corresponder a esse campo, como cada quarto valor ou o intervalo de 1 a 5 com um intervalo de etapas de 2

Exemplo	Expressão Cron
Compilar todas as segundas, quartas e sextas-feiras às 18h	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5 ou 0 18 * * 1-5/2
Compilar a cada 6 horas	0 0,6,12,18 * * *, 0 */6 * * * ou 0 0-18/6 * * *
Compilar a cada 6 horas a partir das 9h	0 9,15,21 * * * ou 0 9-21/6 * * *

Para obter mais informações sobre formatos com suporte, confira Expressão Crontab.

Clássico

Os agendamentos clássicos são definidos usando um editor gráfico, em vez da sintaxe cron. Para obter informações sobre como definir agendas clássicas, confira Exemplos.

Exibição de execuções agendadas

YAML

Você pode exibir uma pré-visualização das próximas compilações agendadas escolhendo Execuções agendadas no menu de contexto na página de detalhes do pipeline do seu pipeline.

Importante

A exibição de execuções agendadas mostra apenas os pipelines agendados para execução no prazo de sete dias a partir da data atual. Se o agendamento cron tiver um intervalo maior que 7 dias e a próxima execução estiver agendada para iniciar após sete dias a partir da data atual, ela não será exibida no modo de exibição de execuções agendadas.

Depois de criar ou atualizar os gatilhos agendados, você pode verificá-los usando essa exibição.

Este exemplo exibe as execuções agendadas para o agendamento a seguir.

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

As janelas Execuções agendadas exibem os horários convertidos no fuso horário local definido no computador usado para navegar até o portal do Azure DevOps. Este exemplo exibe uma captura de tela feita no fuso horário EST.

Clássico

Você pode exibir uma pré-visualização das próximas compilações agendadas escolhendo Execuções agendadas no menu de contexto na página de detalhes do pipeline do seu pipeline.

Depois de criar ou atualizar os gatilhos agendados, você pode verificá-los usando essa exibição.

Como executar mesmo quando não há alteração de código

Por padrão, o pipeline não será executado conforme agendado, se não houver alterações de código desde a última execução agendada bem-sucedida. Por exemplo, considere que você agendou um pipeline para ser executado todas as noites às 21h. Durante os dias da semana, você envia várias alterações ao seu código. O pipeline será executado de acordo com o agendamento. Durante os fins de semana, você não faz alterações no código. Se não houver alterações de código desde a execução agendada na sexta-feira, o pipeline não será executado conforme agendado durante o fim de semana.

YAML

Para forçar a execução de um pipeline mesmo quando não houver alterações de código, você pode usar a palavra-chave always.

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

Clássico

Para configurar o pipeline agendado para compilar somente se houver uma alteração desde a última compilação, marque a opção Agendar builds somente se a origem ou o pipeline tiver sido alterado.

Limites no número de execuções agendadas em pipelines YAML

Existem alguns limites para a frequência com que você pode agendar a execução dos pipelines. Esses limites foram implementados para evitar o uso indevido de recursos do Azure Pipelines, especialmente no caso de agentes hospedados pela Microsoft. Os limites são:

• cerca de 1.000 execuções por pipeline por semana
• 10 execuções por pipeline a cada 15 minutos

Como migrar do editor clássico

Os exemplos a seguir mostram como migrar seus agendamentos do editor clássico para o YAML.

• Exemplo: build noturno do Repositório do Git em vários fusos horários
• Exemplo: build noturno com frequências diferentes

Exemplo: build noturno do Repositório do Git em vários fusos horários

Neste exemplo, o gatilho agendado do editor clássico tem duas entradas, que produzem os builds a seguir.

• Todas as segundas a sextas-feiras às 3h (fuso horário UTC + 5h30), compile branches que atendam aos critérios do filtro de branch features/india/*

  

• Todas as segundas a sextas-feiras às 3h (fuso horário UTC – 5h), compile branches que atendam aos critérios do filtro de branch features/nc/*

  

O gatilho agendado do YAML equivalente é:

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

No primeiro agendamento, build diário de segunda a sexta às 3h (UTC + 5h30) na Índia, a sintaxe cron (mm HH DD MM DW) é 30 21 * * Sun-Thu.

• Minutos e Horas – 30 21 – Isso é mapeado para 21:30 UTC (9:30 PM UTC). Como o fuso horário especificado no editor clássico é UTC + 5h30, precisamos subtrair 5 horas e 30 minutos do horário de build desejado de 3h para chegar ao horário UTC desejado para especificar para o gatilho do YAML.
• Os dias e meses são especificados como curingas, pois esse agendamento não especifica a execução somente em determinados dias do mês ou em um mês específico.
• Dias da semana – Sun-Thu – devido à conversão de fuso horário, para que nossos builds sejam executados às 3h no fuso horário UTC + 5:30 da Índia, precisamos especificar que sejam iniciados no dia anterior no horário UTC. Também podemos especificar os dias da semana como 0-4 ou 0,1,2,3,4.

No segundo agendamento, build diário de segunda a sexta às 3h (UTC - 5) em NC, a sintaxe cron é 0 8 * * Mon-Fri.

• Minutos e Horas – 0 8 – Isso é mapeado para 8:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC - 5h, precisamos adicionar 5 horas a partir do horário de build desejado de 3h para chegar ao horário UTC desejado para especificar para o gatilho do YAML.
• Os dias e meses são especificados como curingas, pois esse agendamento não especifica a execução somente em determinados dias do mês ou em um mês específico.
• Dias da semana – Mon-Fri – Como nossas conversões de fuso horário não abrangem vários dias da semana para o agendamento desejado, não precisamos fazer conversão. Também podemos especificar os dias da semana como 1-5 ou 1,2,3,4,5.

Importante

Os fusos horários UTC nos gatilhos agendados do YAML não levam em conta o horário de verão.

Dica

Ao usar dias da semana com 3 letras e desejar um período de vários dias até dom, dom deve ser considerado o primeiro dia da semana, por exemplo, para um agendamento à meia-noite EST, de quinta a domingo, a sintaxe cron é 0 5 * * Sun,Thu-Sat.

Exemplo: build noturno com frequências diferentes

Neste exemplo, o gatilho agendado do editor clássico tem duas entradas, que produzem os builds a seguir.

• Todas as segundas a sextas-feiras às 3h UTC, compile branches que atendam aos critérios do filtro de branch main e releases/*

  

• Todos os domingos às 3h UTC, compile o branch releases/lastversion, mesmo que a origem ou o pipeline não tenha sido alterado

  

O gatilho agendado do YAML equivalente é:

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

No primeiro agendamento, build diário de segunda a sexta às 3h (UTC), a sintaxe cron é 0 3 * * Mon-Fri.

• Minutos e Horas – 0 3 – Isso é mapeado para 3:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC, não precisamos fazer conversão de fuso horário.
• Os dias e meses são especificados como curingas, pois esse agendamento não especifica a execução somente em determinados dias do mês ou em um mês específico.
• Dias da semana – Mon-Fri – como não há conversão de fuso horário, os dias da semana são mapeados diretamente do agendamento do editor clássico. Também podemos especificar os dias da semana como 1,2,3,4,5.

No segundo agendamento, build semanal da versão mais recente aos domingos às 3h (UTC), a sintaxe cron é 0 3 * * Sun.

• Minutos e Horas – 0 3 – Isso é mapeado para 3:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC, não precisamos fazer conversão de fuso horário.
• Os dias e meses são especificados como curingas, pois esse agendamento não especifica a execução somente em determinados dias do mês ou em um mês específico.
• Dias da semana – Sun – Como nossas conversões de fuso horário não abrangem vários dias da semana para o agendamento desejado, não precisamos fazer conversão. Também podemos especificar os dias da semana como 0.
• Também especificamos always: true, pois esse build foi agendado para ser executado independentemente da atualização do código-fonte.

Perguntas frequentes

• Quero que meu pipeline seja executado somente no agendamento e não quando alguém efetuar push de uma alteração para um branch
• Defini um agendamento no arquivo YAML. Mas ele não foi executado. O que aconteceu?
• Meus agendamentos do YAML estavam funcionando corretamente. No entanto, eles pararam de funcionar agora. Como depurar isso?
• Meu código não foi alterado, mas um build agendado foi disparado. Por quê?
• Vejo a execução planejada no painel Execuções agendadas. No entanto, não é executada nesse momento. Por quê?
• Os agendamentos definidos no pipeline YAML funcionam para um branch, mas não para outro. Como corrigir isso?

Quero que meu pipeline seja executado somente no agendamento e não quando alguém efetuar push de uma alteração para um branch

Se você quiser que o pipeline seja executado apenas no agendamento e não quando alguém enviar uma alteração por push para uma ramificação ou mesclar uma alteração no branch principal, você deverá desabilitar explicitamente os gatilhos padrão de CI e PR no pipeline.

Para desabilitar os gatilhos de CI e PR padrão, adicione as instruções a seguir ao pipeline yaml e verifique se você não substituiu os gatilhos de pipeline YAML por gatilhos de interface do usuário.

trigger: none
pr: none

Para obter mais informações, confira definição de pr e definição de gatilho.

Defini um agendamento no arquivo YAML. Mas ele não foi executado. O que aconteceu?

• Verifique as próximas execuções que o Azure Pipelines agendou para seu pipeline. Você pode encontrar essas execuções selecionando a ação Execuções agendadas no seu pipeline. A lista é filtrada para mostrar apenas as próximas execuções nos próximos dias. Se isso não atender às suas expectativas, provavelmente você digitou incorretamente o agendamento cron ou não definiu o agendamento no branch correto. Leia o tópico acima para entender como configurar agendamentos. Reavalie sua sintaxe cron. Todos os horários para agendamentos cron estão em UTC.

• Faça uma pequena alteração trivial no arquivo YAML e envie essa atualização para o repositório. Se houve algum problema na leitura dos agendamentos do arquivo YAML anteriormente, ele deve ser corrigido agora.

• Se você tiver agendamentos definidos na interface do usuário, seus agendamentos do YAML não serão executados. Verifique se você não tem agendamentos de interface do usuário navegando até o editor do pipeline e selecionando Gatilhos.

• Há um limite no número de execuções que você pode agendar para um pipeline. Leia mais sobre limites.

• Se não houver alteração no código, o Azure Pipelines pode não iniciar novas execuções. Saiba como substituir esse comportamento.

Meus agendamentos do YAML estavam funcionando corretamente. No entanto, eles pararam de funcionar agora. Como depurar isso?

• Se você não especificou always:true, seu pipeline não será agendado, a menos que haja atualizações no seu código. Verifique se houve alterações de código e como você configurou os agendamentos.

• Há um limite de quantas vezes você pode agendar seu pipeline. Verifique se você excedeu esses limites.

• Verifique se alguém habilitou mais agendamentos na interface do usuário. Abra o editor do pipeline e selecione Gatilhos. Se eles definiram agendamentos na interface do usuário, seus agendamentos do YAML não serão executados.

• Verifique se o pipeline está pausado ou desabilitado. Selecione Configurações para seu pipeline.

• Verifique as próximas execuções que o Azure Pipelines agendou para seu pipeline. Você pode encontrar essas execuções selecionando a ação Execuções agendadas no seu pipeline. Se você não vir os agendamentos esperados, faça uma pequena alteração trivial no arquivo YAML e envie a atualização para o repositório. Isso deve ressincronizar os agendamentos.

• Se você usar o GitHub para armazenar seu código, é possível que o Azure Pipelines tenha sido limitado pelo GitHub, quando tentou iniciar uma nova execução. Verifique se você pode iniciar uma nova execução manualmente.

Meu código não foi alterado, mas um build agendado foi disparado. Por quê?

• Você pode ter ativado uma opção para sempre executar um build agendado, mesmo que não haja alterações de código. Se você usar um arquivo YAML, verifique a sintaxe do agendamento no arquivo YAML. Se você usar pipelines clássicos, verifique se marcou essa opção nos gatilhos agendados.

• Você pode ter atualizado o pipeline de build ou alguma propriedade do pipeline. Isso fará com que uma nova execução seja agendada mesmo que você não tenha atualizado o código-fonte. Verifique o Histórico de alterações no pipeline usando o editor clássico.

• Talvez você tenha atualizado a conexão de serviço usada para se conectar ao repositório. Isso fará com que uma nova execução seja agendada mesmo que você não tenha atualizado o código-fonte.

• O Azure Pipelines primeiro verifica se há atualizações no código. Se o Azure Pipelines não conseguir acessar seu repositório ou obter essas informações, ele criará uma execução informativa. É um build fictício para informar que o Azure Pipelines não consegue acessar seu repositório.

• Seu pipeline pode não ter um build completamente bem-sucedido. Para determinar se um novo build deve ser agendado, o Azure DevOps pesquisa o último build agendado completamente bem-sucedido. Se ele não encontrar um, disparará um novo build agendado. Os builds agendados parcialmente bem-sucedidos não são considerados bem-sucedidos. Portanto, se o pipeline tiver apenas builds parcialmente bem-sucedidos, o Azure DevOps disparará builds agendados, mesmo que seu código não tenha sido alterado.

Vejo a execução planejada no painel Execuções agendadas. No entanto, não é executada nesse momento. Por quê?

• O painel Execuções agendadas mostra todos os agendamentos potenciais. No entanto, ele pode não ser executado, a menos que você tenha feito atualizações reais no código. Para forçar um agendamento a ser sempre executado, verifique se você definiu a propriedade always no pipeline YAML ou marcou a opção para executar sempre em um pipeline clássico.

Os agendamentos definidos no pipeline YAML funcionam para um branch, mas não para outro. Como corrigir isso?

Os agendamentos são definidos em arquivos YAML e esses arquivos são associados a branches. Se você quiser que um pipeline seja agendado para um branch específico, digamos features/X, verifique se o arquivo YAML nesse branch tem o agendamento cron definido e se ele tem as inclusões de branch corretas para o agendamento. O arquivo YAML no branch features/X deve ter o seguinte schedule neste exemplo:

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

Para obter mais informações, confira Considerações de branch para gatilhos agendados.