Configurar agendamentos para pipelines

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

Migrando do editor clássico

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

• Exemplo: compilação noturna do repositório Git em vários fusos horários
• Exemplo: Construção noturna com diferentes frequências

Exemplo: compilação noturna do repositório Git em vários fusos horários

Neste exemplo, o gatilho agendado do editor clássico tem duas entradas, produzindo as compilações a seguir.

• Todas as segundas e sextas-feiras às 3:00 (UTC + 5:30 fuso horário), construa ramificações que atendam aos critérios de filtro de features/india/* ramificação

  

• Todas as segundas e sextas-feiras às 3:00 (UTC - 5:00 fuso horário), construa ramificações que atendam aos critérios de filtro de features/nc/* ramificação

  

O gatilho agendado 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 horário, M-F 3:00 AM (UTC + 5:30) India daily build, a sintaxe cron (mm HH DD MM DW) é 30 21 * * Sun-Thu.

• Minutos e Horas - 30 21 - Este mapeia para 21:30 UTC (9:30 PM UTC). Como o fuso horário especificado no editor clássico é UTC + 5:30, precisamos subtrair 5 horas e 30 minutos do tempo de compilação desejado de 3:00 AM para chegar ao horário UTC desejado para especificar para o gatilho YAML.
• Dias e Meses são especificados como curingas, pois essa programação não especifica para ser executada apenas em determinados dias do mês ou em um mês específico.
• Dias da semana - Sun-Thu - por causa da conversão de fuso horário, para que nossas compilações sejam executadas às 3:00 AM no fuso horário UTC + 5:30 Índia, precisamos especificar iniciá-las 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 horário, M-F 3:00 AM (UTC - 5) NC compilação diária, a sintaxe cron é 0 8 * * Mon-Fri.

• Minutos e Horas - 0 8 - Este mapeia para 8:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC - 5:00, precisamos adicionar 5 horas a partir do tempo de compilação desejado de 3:00 AM para chegar ao horário UTC desejado para especificar para o gatilho YAML.
• Dias e Meses são especificados como curingas, pois essa programação não especifica para ser executada apenas 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 nossa programação desejada, não precisamos fazer nenhuma conversão aqui. Também podemos especificar os dias da semana como 1-5 ou 1,2,3,4,5.

Exemplo: Construção noturna com diferentes frequências

Neste exemplo, o gatilho agendado do editor clássico tem duas entradas, produzindo as compilações a seguir.

• Todas as segundas e sextas-feiras às 3:00 AM UTC, construa ramificações que atendam aos critérios de main filtro e releases/* ramificação

  

• Todos os domingos às 3:00 AM UTC, construa a releases/lastversion ramificação, mesmo que a fonte ou pipeline não tenha mudado

  

O gatilho agendado 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

Na primeira programação, M-F 3:00 AM (UTC) compilação diária, a sintaxe cron é 0 3 * * Mon-Fri.

• Minutos e Horas - 0 3 - Este mapeia para 3:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC, não precisamos fazer nenhuma conversão de fuso horário.
• Dias e Meses são especificados como curingas, pois essa programação não especifica para ser executada apenas em determinados dias do mês ou em um mês específico.
• Dias da semana - Mon-Fri - porque não há conversão de fuso horário, os dias da semana são mapeados diretamente da programação clássica do editor. Também poderíamos especificar os dias da semana como 1,2,3,4,5.

No segundo horário, domingo 3:00 AM (UTC) compilação semanal última versão, a sintaxe cron é 0 3 * * Sun.

• Minutos e Horas - 0 3 - Este mapeia para 3:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC, não precisamos fazer nenhuma conversão de fuso horário.
• Dias e Meses são especificados como curingas, pois essa programação não especifica para ser executada apenas 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 nossa programação desejada, não precisamos fazer nenhuma conversão aqui. Também poderíamos especificar os dias da semana como 0.
• Também especificamos always: true , uma vez que esta compilação está agendada para ser executada, independentemente de o código-fonte ter sido atualizado ou não.

FAQ

• Quero que meu pipeline seja executado apenas no cronograma e não quando alguém empurra uma alteração para uma filial
• Defini um cronograma no arquivo YAML. Mas não correu. O que aconteceu?
• Meus horários YAML estavam funcionando bem. Mas, eles pararam de trabalhar agora. Como faço para depurar isso?
• Meu código não foi alterado, mas uma compilação agendada foi acionada. Porquê?
• Vejo a execução planejada no painel Execuções agendadas. No entanto, ele não é executado nesse momento. Porquê?
• As agendas definidas no trabalho de pipeline YAML para uma ramificação, mas não para a outra. Como devo proceder para corrigir este problema?

Quero que meu pipeline seja executado apenas no cronograma e não quando alguém empurra uma alteração para uma filial

Se você quiser que seu pipeline seja executado apenas na agenda, e não quando alguém envia uma alteração para uma ramificação ou mescla uma alteração para a ramificação principal, você deve desabilitar explicitamente os gatilhos de CI e PR padrão no pipeline.

Para desabilitar os gatilhos de CI e PR padrão, adicione as instruções a seguir ao seu 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, consulte definição pr e definição de gatilho.

Defini um cronograma no arquivo YAML. Mas não correu. O que aconteceu?

• Verifique as próximas execuções que o Azure Pipelines programou para seu pipeline. Você pode encontrar essas execuções selecionando a ação Execuções agendadas em seu pipeline. A lista é filtrada para mostrar apenas as próximas corridas nos próximos dias. Se isso não atender às suas expectativas, provavelmente é o caso de você ter digitado incorretamente seu cronograma cron, ou você não tem o cronograma definido na ramificação correta. Leia o tópico acima para entender como configurar agendas. Reavalie sua sintaxe cron. Todos os horários para horários cron estão em UTC.

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

• Se você tiver quaisquer agendas definidas na interface do usuário, suas agendas YAML não serão honradas. Certifique-se de que você não tenha nenhuma agenda de interface do usuário navegando até o editor do seu pipeline e selecionando Triggers.

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

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

Meus horários YAML estavam funcionando bem. Mas, eles pararam de trabalhar agora. Como faço para depurar isso?

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

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

• Verifique se alguém ativou mais agendas na interface do usuário. Abra o editor do pipeline e selecione Triggers. Se eles definiram agendas na interface do usuário, suas agendas YAML não serão honradas.

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

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

• 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 uma compilação agendada foi acionada. Porquê?

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

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

• Você pode ter 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 seu código-fonte.

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

• Seu pipeline pode não ter uma compilação completamente bem-sucedida. Para determinar se uma nova compilação deve ser agendada ou não, o Azure DevOps procura a última compilação agendada completamente bem-sucedida. Se não encontrar um, ele aciona uma nova compilação agendada. Compilações agendadas parcialmente bem-sucedidas não são consideradas bem-sucedidas, portanto, se seu pipeline tiver apenas compilações parcialmente bem-sucedidas, o Azure DevOps acionará compilações agendadas, mesmo que seu código não tenha sido alterado.

Vejo a execução planejada no painel Execuções agendadas. No entanto, ele não é executado nesse momento. Porquê?

• O painel Execuções agendadas mostra todas as agendas potenciais. No entanto, ele pode realmente não ser executado, a menos que você tenha feito atualizações reais para o código. Para forçar uma programação a ser sempre executada, certifique-se de ter definido a propriedade always no pipeline YAML ou marcado a opção de sempre executar em um pipeline clássico.

As agendas definidas no trabalho de pipeline YAML para uma ramificação, mas não para a outra. Como devo proceder para corrigir este problema?

As agendas são definidas em arquivos YAML e esses arquivos são associados a ramificações. Se você quiser que um pipeline seja agendado para uma ramificação específica, digamos features/X, certifique-se de que o arquivo YAML nessa ramificação tenha o cronograma cron definido nele e que ele tenha as inclusões de ramificação corretas para o agendamento. O arquivo YAML na features/X ramificação 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, consulte Considerações de ramificação para gatilhos agendados.