Configurar agendamentos para pipelines

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

O Azure Pipelines fornece vários tipos de gatilhos para configurar como o seu pipeline começa.

• Os gatilhos agendados iniciam seu pipeline com base em uma programação, como uma compilação noturna. Este artigo fornece orientação sobre como usar gatilhos agendados para executar os seus pipelines com base em uma agenda.
• Os gatilhos baseados em eventos iniciam o pipeline em resposta a eventos, como a criação de um pull request ou o envio por push para uma ramificação. 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 a compilação sempre que um push é feito (gatilho CI), quando uma solicitação pull é feita (gatilho PR) e uma compilação noturna (gatilho agendado). Se você quiser criar seu pipeline somente em um cronograma, e não em resposta a gatilhos baseados em eventos, certifique-se de que seu pipeline não tenha nenhum outro gatilho habilitado. Por exemplo, pipelines YAML num repositório do GitHub têm gatilhos de CI e PR ativados 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 aborda seu tipo de repositório.

Acionadores 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

Visualização de execuções agendadas

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

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

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, tu fazes várias alterações ao teu código. O processo é 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.

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

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, resultando nas compilações a seguir.

• De segunda a sexta-feira, às 3:00 da manhã (fuso horário UTC + 5:30), construa ramificações que atendam aos critérios de filtro de ramificação features/india/*.

  

• Todas as segunda a sexta-feira às 3:00 (hora UTC - 5:00), construir ramificações que atendam aos critérios do filtro da ramificação features/nc/*.

  

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. Você pode obter assistência de IA do GitHub Copilot para criar sua expressão cron.
• Dias e meses são especificados como coringas, pois esta programação não especifica para ser executada apenas em determinados dias do mês ou num mês específico.
• Dias da semana - Sun-Thu - devido à conversão de fuso horário, para que os nossos processos sejam executados às 3:00 AM no fuso horário UTC+5:30 da Índia, precisamos especificar iniciá-los 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, Seg-Sex 3:00 AM (UTC - 5) NC versão diária, a sintaxe cron é 0 8 * * Mon-Fri.

• Minutos e Horas - 0 8 - Isto é mapeado 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. Você pode obter assistência de IA do GitHub Copilot para criar sua expressão cron.
• Dias e meses são especificados como coringas, pois esta programação não especifica para ser executada apenas em determinados dias do mês ou num 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, resultando nas compilações a seguir.

• De segunda a sexta-feira às 3:00 AM UTC, construa as ramificações que atendam aos critérios dos filtros de ramificação main e releases/*.

  

• Todos os domingos às 3:00 da manhã UTC, construa a ramificação releases/lastversion, mesmo que a origem ou o 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 - Isto é mapeado 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 coringas, pois esta programação não especifica para ser executada apenas em determinados dias do mês ou num 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, às 03:00 horas (UTC), compilação da última versão semanal, a sintaxe cron é 0 3 * * Sun.

• Minutos e Horas - 0 3 - Isto é mapeado 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 coringas, pois esta programação não especifica para ser executada apenas em determinados dias do mês ou num 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?
• As minhas agendas YAML estavam a funcionar 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 Executões programadas. No entanto, não é executado a essa altura. Porquê?
• Os horários definidos no pipeline YAML funcionam 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 pretenderes que o teu pipeline seja executado apenas conforme o agendamento, e não quando alguém envia uma alteração para uma ramificação ou funde uma alteração à ramificação principal, deves desativar explicitamente os disparadores 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 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 agendamentos 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.

As minhas agendas YAML estavam a funcionar bem. Mas, eles pararam de trabalhar agora. Como faço para depurar isso?

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

• Há um limite de quantas vezes pode agendar o 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 não visualizar os horários esperados, faça uma pequena alteração trivial no arquivo YAML e submeta 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 utilizar um ficheiro YAML, verifique a sintaxe para a agenda no ficheiro 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. Confira o histórico de alterações na linha de processamento 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.

• O seu pipeline pode não ter tido uma construçã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 compilação agendada nova. 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 Executões programadas. No entanto, não é executado a essa altura. 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 executar sempre num pipeline clássico.

Os horários definidos no pipeline YAML funcionam 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.