Configurar agendamentos para pipelines

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

O Azure Pipelines fornece vários tipos de gatilhos para configurar como o pipeline é 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 por push para um branch. Para obter informações sobre como usar gatilhos baseados em eventos, consulte Gatilhos no Azure Pipelines.

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

Gatilhos agendados

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 or pipeline settings 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

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

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

# 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

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

Exemplos

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

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

Build a UTC cron expression for Monday, Wednesday, and Friday at 6:00 PM Eastern Standard Time

Convert the following cron expression from Eastern Standard Time to UTC: 0 18 * * Mon,Wed,Fri

Build a UTC cron expression for Monday through Friday at 12:30 AM Central European Standard Time

Build a UTC cron expression for Monday through Friday at 12:30 AM Central European Standard Time and explain the different parts of the cron expression

Exibição de execuções agendadas

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

Executando mesmo quando não há alterações de código

Por padrão, o pipeline não será executado como agendado se não houver nenhuma alteração 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 por push ao seu código. O pipeline é executado de acordo com o agendamento. Durante os fins de semana, você não faz nenhuma alteração 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 como agendado durante o fim de semana.

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

Migrando 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 Git em vários fusos horários
• Exemplo: compilação noturna com frequências diferentes

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

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

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

  

• Todas as segundas-feiras - sextas-feiras às 3:00 da manhã (UTC - 5:00 fuso horário), crie branches que atendam aos critérios de filtro de features/nc/* filial

  

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

Na primeira agenda, M-F 3:00 AM (UTC + 5:30) Compilação diária da Índia, a sintaxe cron (mm HH DD MM DW) é 30 21 * * Sun-Thu.

• Minutos e Horas - 30 21 - Isso 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 build desejado de 3:00 para chegar no horário UTC desejado para especificar o gatilho YAML. Você pode obter assistência de IA do GitHub Copilot para criar sua expressão cron.
• 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 por causa da conversão de fuso horário, para que nossos builds sejam executados às 3:00 da manhã no fuso horário UTC + 5:30 índia, precisamos especificar a inicialização deles 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, M-F 3:00 AM (UTC – 5) NC build diário, a sintaxe cron é 0 8 * * Mon-Fri.

• Minutos e Horas - 0 8 - Isso 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 build desejado de 3:00 da manhã para chegar ao horário UTC desejado para especificar para o gatilho YAML. Você pode obter assistência de IA do GitHub Copilot para criar sua expressão cron.
• 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 nossa agenda 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: compilação noturna com frequências diferentes

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

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

  

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

  

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

No primeiro agendamento, m-f 3:00 am (UTC) compilação diária, a sintaxe cron é 0 3 * * Mon-Fri.

• Minutos e Horas - 0 3 - Isso mapeia para 3:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC, não precisamos fazer conversões de fuso horário.
• 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 porque não há conversão de fuso horário, os dias da semana mapeiam diretamente da agenda do editor clássico. Também poderíamos especificar os dias da semana como 1,2,3,4,5.

Na segunda agenda, domingo, às 3:00 da manhã (UTC) versão mais recente, a sintaxe cron é 0 3 * * Sun.

• Minutos e Horas - 0 3 - Isso mapeia para 3:00 AM UTC. Como o fuso horário especificado no editor clássico é UTC, não precisamos fazer conversões de fuso horário.
• 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 nossa agenda 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 esse build está agendado para ser executado se o código-fonte foi ou não atualizado.

perguntas frequentes

• Quero que meu pipeline seja executado apenas no agendamento e não quando alguém enviar uma alteração por push para um branch
• Defini um agendamento no arquivo YAML. Mas não correu. O que aconteceu?
• Meus horários yaml estavam funcionando bem. Mas eles pararam de trabalhar agora. Como fazer para depurar isso?
• Meu código não foi alterado, mas um build agendado é disparado. Por que?
• Vejo a execução planejada no painel de execuções agendadas. No entanto, ele não é executado nesse momento. Por que?
• Os agendamentos definidos no pipeline do YAML funcionam para um branch, mas não para o outro. Como posso corrigir isso?

Quero que meu pipeline seja executado apenas no agendamento e não quando alguém enviar uma alteração por push para um branch

Se você quiser que seu pipeline seja executado apenas no agendamento e não quando alguém enviar uma alteração por push para um branch 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 padrão de CI e PR, adicione as instruções a seguir ao pipeline yaml e verifique se você não substituiu os gatilhos de pipeline YAML com gatilhos de interface do usuário.

trigger: none
pr: none

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

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

• Verifique as próximas execuções que o Azure Pipelines agendou para o 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 execuções nos próximos dias. Se isso não atender às suas expectativas, provavelmente é o caso de você ter digitado incorretamente sua agenda de cron ou não ter a agenda definida no branch correto. Leia o tópico acima para entender como configurar agendas. Reavaliar sua sintaxe cron. Todas as horas para agendamentos cron estão em UTC.

• Faça uma pequena alteração trivial no arquivo YAML e envie essa atualização por push para o repositório. Se houver algum problema ao ler os agendamentos do arquivo YAML anteriormente, ele deverá ser corrigido agora.

• Se você tiver agendas definidas na interface do usuário, os agendamentos do YAML não serão respeitados. Verifique se você não tem agendas 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 nenhuma alteração no código, o Azure Pipelines poderá 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 fazer para depurar isso?

• Se você não especificou always:true, o pipeline não será agendado, a menos que haja atualizações feitas em 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 agendas na interface do usuário. Abra o editor do pipeline e selecione Gatilhos. Se eles definirem agendas na interface do usuário, os agendamentos do YAML não serão respeitados.

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

• Verifique as próximas execuções que o Azure Pipelines agendou para o pipeline. Você pode encontrar essas execuções selecionando a ação Execuções agendadas em 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 por push 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 ele 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 é disparado. Por que?

• Você pode ter habilitado 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 da agenda no arquivo YAML. Se você usar pipelines clássicos, verifique se verificou 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 se você não tiver atualizado o 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 se você não tiver atualizado o código-fonte.

• O Azure Pipelines verifica primeiro 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. É uma compilação fictícia para informar que o Azure Pipelines não consegue acessar seu repositório.

• O pipeline pode não ter uma compilação completamente bem-sucedida. Para determinar se um novo build ou não deve ser agendado, o Azure DevOps pesquisa o último build agendado completamente bem-sucedido. Se ele não encontrar um, ele disparará um novo build agendado. 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 de execuções agendadas. No entanto, ele não é executado nesse momento. Por que?

• O painel De 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 uma agenda a ser sempre executada, verifique se você definiu a propriedade always no pipeline YAML ou verificou a opção para sempre ser executada em um pipeline clássico.

Os agendamentos definidos no pipeline do YAML funcionam para um branch, mas não para o outro. Como posso 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 features/X branch 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 as considerações do Branch para gatilhos agendados.