Configuración de programaciones para canalizaciones

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

Azure Pipelines proporciona varios tipos de desencadenadores para configurar cómo se inicia la canalización.

• Los desencadenadores programados inician la canalización según una programación, como una compilación nocturna. En este artículo se proporcionan instrucciones sobre el uso de desencadenadores programados para ejecutar las canalizaciones según una programación.
• Los desencadenadores basados en eventos inician la canalización en respuesta a eventos, como la creación de una solicitud de incorporación de cambios o la inserción en una rama. Para obtener información sobre el uso de desencadenadores basados en eventos, consulte Desencadenadores en Azure Pipelines.

Puede combinar desencadenadores programados y basados en eventos en las canalizaciones, por ejemplo, para validar la compilación cada vez que se realiza una inserción (desencadenador de CI), cuando se realiza una solicitud de incorporación de cambios (desencadenador de pr) y una compilación nocturna (desencadenador programado). Si desea compilar la canalización solo según una programación y no en respuesta a los desencadenadores basados en eventos, asegúrese de que la canalización no tiene ningún otro desencadenador habilitado. Por ejemplo, las canalizaciones de YAML en un repositorio de GitHub tienen desencadenadores de CI y desencadenadores de PR habilitados de forma predeterminada. Para obtener información sobre cómo deshabilitar desencadenadores predeterminados, consulte Desencadenadores en Azure Pipelines y vaya a la sección que cubre el tipo de repositorio.

Desencadenadores programados

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

Examples

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

Vista ejecuciones programadas

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

Ejecución incluso cuando no hay cambios en el código

De forma predeterminada, la canalización no se ejecuta como programada si no se han producido cambios en el código desde la última ejecución programada correcta. Por ejemplo, tenga en cuenta que ha programado una canalización para que se ejecute cada noche a las 9:00 p. m. Durante los días laborables, se insertan varios cambios en el código. La canalización se ejecuta según la programación. Durante los fines de semana, no realiza ningún cambio en el código. Si no se han producido cambios en el código desde la ejecución programada el viernes, la canalización no se ejecuta según lo programado durante el fin de semana.

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

Migración desde el editor clásico

En los ejemplos siguientes se muestra cómo migrar las programaciones del editor clásico a YAML.

• Ejemplo: Compilación nocturna del repositorio de Git en varias zonas horarias
• Ejemplo: Compilación nocturna con diferentes frecuencias

Ejemplo: Compilación nocturna del repositorio de Git en varias zonas horarias

En este ejemplo, el desencadenador programado del editor clásico tiene dos entradas, lo que genera las siguientes compilaciones.

• Todos los lunes a viernes a las 3:00 (UTC + 5:30 zona horaria), cree ramas que cumplan los criterios de filtro de features/india/* rama.

  

• Todos los lunes a viernes a las 3:00 (UTC - 5:00 zona horaria), cree ramas que cumplan los criterios de filtro de features/nc/* rama

  

El desencadenador programado de YAML equivalente es:

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

En la primera programación, M-F 3:00 (UTC + 5:30) Compilación diaria de India, la sintaxis cron (mm HH DD MM DW) es 30 21 * * Sun-Thu.

• Minutos y horas: 30 21 se asigna a 21:30 UTC (9:30 PM UTC). Dado que la zona horaria especificada en el editor clásico es UTC + 5:30, necesitamos restar 5 horas y 30 minutos de la hora de compilación deseada de 3:00 AM para llegar a la hora UTC deseada para especificar para el desencadenador YAML. Puede obtener ayuda de IA de GitHub Copilot para crear la expresión cron.
• Los días y meses se especifican como caracteres comodín, ya que esta programación no especifica que se ejecute solo en determinados días del mes o en un mes específico.
• Días de la semana: Sun-Thu debido a la conversión de zona horaria, para que nuestras compilaciones se ejecuten a las 3:00 a.m. en la zona horaria UTC + 5:30 india, es necesario especificar que se inicien el día anterior en hora UTC. También podríamos especificar los días de la semana como 0-4 o 0,1,2,3,4.

En la segunda programación, la compilación diaria M-F 3:00 (UTC - 5) NC, la sintaxis cron es 0 8 * * Mon-Fri.

• Minutos y horas: 0 8 : se asigna a 8:00 AM UTC. Dado que la zona horaria especificada en el editor clásico es UTC - 5:00, es necesario agregar 5 horas a partir de la hora de compilación deseada de 3:00 AM para llegar a la hora UTC deseada para especificar para el desencadenador YAML. Puede obtener ayuda de IA de GitHub Copilot para crear la expresión cron.
• Los días y meses se especifican como caracteres comodín, ya que esta programación no especifica que se ejecute solo en determinados días del mes o en un mes específico.
• Días de la semana: Mon-Fri porque nuestras conversiones de zona horaria no abarcan varios días de la semana para nuestra programación deseada, no es necesario realizar ninguna conversión aquí. También podríamos especificar los días de la semana como 1-5 o 1,2,3,4,5.

Ejemplo: Compilación nocturna con diferentes frecuencias

En este ejemplo, el desencadenador programado del editor clásico tiene dos entradas, lo que genera las siguientes compilaciones.

• Todos los lunes: viernes a las 3:00 UTC, compile ramas que cumplan los criterios de filtro de main rama y releases/*

  

• Todos los domingos a las 3:00 UTC, compile la releases/lastversion rama, incluso si el origen o la canalización no han cambiado

  

El desencadenador programado de YAML equivalente es:

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

En la primera programación, la compilación diaria de M-F 3:00 (UTC), la sintaxis cron es 0 3 * * Mon-Fri.

• Minutos y horas: 0 3 : se asigna a 3:00 AM UTC. Dado que la zona horaria especificada en el editor clásico es UTC, no es necesario realizar ninguna conversión de zona horaria.
• Los días y meses se especifican como caracteres comodín, ya que esta programación no especifica que se ejecute solo en determinados días del mes o en un mes específico.
• Días de la semana : Mon-Fri porque no hay ninguna conversión de zona horaria, los días del mapa de la semana directamente desde la programación del editor clásico. También podríamos especificar los días de la semana como 1,2,3,4,5.

En la segunda programación, la compilación de la versión más reciente semanal del domingo 3:00 (UTC), la sintaxis cron es 0 3 * * Sun.

• Minutos y horas: 0 3 : se asigna a 3:00 AM UTC. Dado que la zona horaria especificada en el editor clásico es UTC, no es necesario realizar ninguna conversión de zona horaria.
• Los días y meses se especifican como caracteres comodín, ya que esta programación no especifica que se ejecute solo en determinados días del mes o en un mes específico.
• Días de la semana: Sun porque nuestras conversiones de zona horaria no abarcan varios días de la semana para nuestra programación deseada, no es necesario realizar ninguna conversión aquí. También podríamos especificar los días de la semana como 0.
• También se especifica always: true , ya que esta compilación está programada para ejecutarse si se ha actualizado o no el código fuente.

Preguntas más frecuentes

• Quiero que mi canalización solo se ejecute según la programación y no cuando alguien inserte un cambio en una rama
• He definido una programación en el archivo YAML. Pero no se ejecutó. ¿¿Qué pasó?
• Mis programaciones de YAML funcionaban bien. Pero dejaron de trabajar ahora. ¿Cómo puedo depurar esto?
• Mi código no ha cambiado, pero se desencadena una compilación programada. ¿Por qué?
• Veo la ejecución planeada en el panel Ejecuciones programadas. Sin embargo, no se ejecuta en ese momento. ¿Por qué?
• Programaciones definidas en el trabajo de canalización de YAML para una rama, pero no para la otra. ¿Cómo lo arreglo?

Quiero que mi canalización solo se ejecute según la programación y no cuando alguien inserte un cambio en una rama

Si desea que la canalización se ejecute solo según la programación y no cuando alguien inserte un cambio en una rama o combine un cambio en la rama principal, debe deshabilitar explícitamente los desencadenadores de CI y PR predeterminados en la canalización.

Para deshabilitar los desencadenadores predeterminados de CI y PR, agregue las siguientes instrucciones a la canalización de YAML y compruebe que no ha invalidado los desencadenadores de canalización de YAML con desencadenadores de interfaz de usuario.

trigger: none
pr: none

Para obtener más información, consulte definición de pr y definición de desencadenador.

He definido una programación en el archivo YAML. Pero no se ejecutó. ¿¿Qué pasó?

• Compruebe las siguientes ejecuciones que Azure Pipelines ha programado para la canalización. Para encontrar estas ejecuciones, seleccione la acción Ejecuciones programadas en la canalización. La lista se filtra para mostrar solo las próximas ejecuciones en los próximos días. Si esto no cumple con sus expectativas, probablemente sea el caso de que haya escrito mal la programación cron o que no tenga la programación definida en la rama correcta. Lea el tema anterior para comprender cómo configurar programaciones. Vuelva a evaluar la sintaxis cron. Todas las horas de las programaciones cron están en UTC.

• Realice un pequeño cambio trivial en el archivo YAML e inserte esa actualización en el repositorio. Si hay algún problema al leer las programaciones del archivo YAML anteriormente, debería corregirse ahora.

• Si tiene alguna programación definida en la interfaz de usuario, no se respetan las programaciones de YAML. Asegúrese de que no tiene ninguna programación de interfaz de usuario; para ello, vaya al editor de la canalización y, a continuación, seleccione Desencadenadores.

• Hay un límite en el número de ejecuciones que puede programar para una canalización. Obtenga más información sobre los límites.

• Si no hay ningún cambio en el código, es posible que Azure Pipelines no inicie nuevas ejecuciones. Obtenga información sobre cómo invalidar este comportamiento.

Mis programaciones de YAML funcionaban bien. Pero dejaron de trabajar ahora. ¿Cómo puedo depurar esto?

• Si no ha especificado always:true, la canalización no se programará a menos que haya actualizaciones realizadas en el código. Compruebe si se han producido cambios en el código y cómo configuró las programaciones.

• Hay un límite en el número de veces que se puede programar la canalización. Compruebe si ha superado esos límites.

• Compruebe si alguien ha habilitado más programaciones en la interfaz de usuario. Abra el editor de la canalización y seleccione Desencadenadores. Si definieron programaciones en la interfaz de usuario, no se respetarán las programaciones de YAML.

• Compruebe si la canalización está en pausa o deshabilitada. Seleccione Configuración para la canalización.

• Compruebe las siguientes ejecuciones que Azure Pipelines ha programado para la canalización. Para encontrar estas ejecuciones, seleccione la acción Ejecuciones programadas en la canalización. Si no ve las programaciones que esperaba, realice un pequeño cambio trivial en el archivo YAML e inserte la actualización en el repositorio. Esto debe resincronizar las programaciones.

• Si usa GitHub para almacenar el código, es posible que GitHub haya limitado Azure Pipelines cuando intentó iniciar una nueva ejecución. Compruebe si puede iniciar una nueva ejecución manualmente.

Mi código no ha cambiado, pero se desencadena una compilación programada. ¿Por qué?

• Es posible que haya habilitado una opción para ejecutar siempre una compilación programada aunque no haya cambios en el código. Si usa un archivo YAML, compruebe la sintaxis de la programación en el archivo YAML. Si usa canalizaciones clásicas, compruebe si ha activado esta opción en los desencadenadores programados.

• Es posible que haya actualizado la canalización de compilación o alguna propiedad de la canalización. Esto hará que se programe una nueva ejecución incluso si no ha actualizado el código fuente. Compruebe el historial de cambios en la canalización mediante el editor clásico.

• Es posible que haya actualizado la conexión de servicio utilizada para conectarse al repositorio. Esto hará que se programe una nueva ejecución incluso si no ha actualizado el código fuente.

• Azure Pipelines comprueba primero si hay actualizaciones en el código. Si Azure Pipelines no puede acceder al repositorio o obtener esta información, creará una ejecución informativa. Se trata de una compilación ficticia para informarle de que Azure Pipelines no puede acceder al repositorio.

• Es posible que la canalización no tenga una compilación completamente correcta. Para determinar si se debe programar una nueva compilación o no, Azure DevOps busca la última compilación programada correcta por última vez. Si no encuentra una, desencadena una nueva compilación programada. Las compilaciones programadas parcialmente correctas no se consideran correctas, por lo que si la canalización solo tiene compilaciones parcialmente correctas, Azure DevOps desencadenará compilaciones programadas, incluso si el código no ha cambiado.

Veo la ejecución planeada en el panel Ejecuciones programadas. Sin embargo, no se ejecuta en ese momento. ¿Por qué?

• El panel Ejecuciones programadas muestra todas las programaciones posibles. Sin embargo, es posible que realmente no se ejecute a menos que haya realizado actualizaciones reales en el código. Para forzar que una programación siempre se ejecute, asegúrese de que ha establecido la propiedad always en la canalización YAML o de que ha activado la opción para ejecutarse siempre en una canalización clásica.

Programaciones definidas en el trabajo de canalización de YAML para una rama, pero no para la otra. ¿Cómo lo arreglo?

Las programaciones se definen en archivos YAML y estos archivos están asociados a ramas. Si desea que una canalización se programe para una rama determinada, por ejemplo features/X, asegúrese de que el archivo YAML de esa rama tiene definida la programación cron y que tiene las inclusiones de rama correctas para la programación. El archivo YAML de la features/X rama debe tener lo siguiente schedule en este ejemplo:

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

Para obtener más información, consulte Consideraciones de rama para desencadenadores programados.