Configurar agendamentos para pipelines

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.

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.

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.