Configuración de programaciones para las canalizaciones

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

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 la ejecución de las canalizaciones según una programación con desencadenadores programados.
• 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 más 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 realice una inserción (desencadenador de CI), cuando se realice 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 esta no tenga 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 información sobre cómo deshabilitar los desencadenadores predeterminados, consulte Desencadenadores en Azure Pipelines y vaya a la sección que trata del tipo de repositorio en concreto.

Desencadenadores programados

YAML

Importante

Los desencadenadores programados definidos mediante la interfaz de usuario de configuración de canalización tienen prioridad sobre los desencadenadores programados de YAML.

Si la canalización de YAML tiene desencadenadores programados de YAML y desencadenadores programados definidos por la interfaz de usuario, solo se ejecutan los desencadenadores programados definidos por la interfaz de usuario. Para ejecutar los desencadenadores programados definidos por YAML en la canalización YAML, debe quitar los desencadenadores programados definidos en la interfaz de usuario de configuración de canalización. Una vez quitados todos los desencadenadores programados de la interfaz de usuario, se debe realizar un envío de cambios para que los desencadenadores programados de YAML empiecen a evaluarse.

Para eliminar desencadenadores programados de la interfaz de usuario de una canalización YAML, consulte Configuración de la interfaz de usuario que invalida los desencadenadores programados de YAML.

Los desencadenadores programados configuran una canalización para que se ejecute según una programación definida mediante la sintaxis cron.

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

Las canalizaciones programadas en YAML tienen las siguientes restricciones.

• La zona horaria de las programaciones cron es UTC.
• Especificar una cláusula exclude sin una cláusula include para branches es equivalente a especificar * en la cláusula include.
• No se pueden usar variables de canalización al especificar programaciones.
• Si usa plantillas en el archivo YAML, las programaciones deben especificarse en el archivo YAML principal y no en los archivos de plantilla.

Consideraciones de rama para los desencadenadores programados

Los desencadenadores programados se evalúan para una rama cuando se producen los siguientes eventos.

• Se crea una canalización.
• Se actualiza el archivo YAML de una canalización, ya sea desde una inserción o editándolo en el editor de canalizaciones.
• La ruta de acceso del archivo YAML de una canalización se actualiza para hacer referencia a un archivo YAML diferente. Este cambio solo actualiza la rama predeterminada y, por tanto, solo recoge las programaciones del archivo YAML actualizado para la rama predeterminada. Si cualquier otra rama combina posteriormente la rama predeterminada, por ejemplo, git pull origin main, los desencadenadores programados del archivo YAML al que ahora se hace referencia se evalúan para esa rama.
• Se crea una rama.

Después de que se produzca uno de estos eventos en una rama, se agregan las ejecuciones programadas para esa rama si esa rama coincide con los filtros de rama de los desencadenadores programados del archivo YAML de esa rama.

Importante

Las ejecuciones programadas para una rama solo se agregan si la rama coincide con los filtros de rama de los desencadenadores programados en el archivo YAML de esa rama en concreto.

Por ejemplo, se crea una canalización con la programación siguiente y esta versión del archivo YAML se comprueba en la rama main. Esta programación compila la rama main diariamente.

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

A continuación, se crea una nueva rama basada en main, denominada new-feature. Los desencadenadores programados del archivo YAML de la nueva rama se leen y, dado que no hay ninguna coincidencia para la rama new-feature, no se realizan cambios en las compilaciones programadas y la rama new-feature no se compila mediante un desencadenador programado.

Si new-feature se agrega a la lista branches y este cambio se inserta en la rama new-feature, se lee el archivo YAML y, como new-feature ahora está en la lista de ramas, se agrega una compilación programada para la rama new-feature.

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

Ahora, tenga en cuenta que se crea una rama denominada release en función de main y, a continuación, release se agrega a los filtros de rama en el archivo YAML de la rama main, pero no en la rama release recién creada.

# 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

Dado que release se agregó a los filtros de rama de la rama main, pero no a los filtros de rama de la rama release, la rama release no se compilará según esa programación. Solo cuando la rama release se agrega a los filtros de rama en el archivo YAML de la rama de versión, la compilación programada se agrega al programador.

Consideraciones sobre lotes para los desencadenadores programados

La propiedad batch configura si se debe ejecutar la canalización si la ejecución programada previamente está en curso; el valor predeterminado es false. Esta acción se realiza independientemente de la versión del repositorio de canalización.

La siguiente tabla describe cómo interactúan always e batch.

Siempre	Batch	Comportamiento
false	false	La canalización solo se ejecuta si hay un cambio con respecto a la última ejecución de canalización programada correcta.
false	true	La canalización solo se ejecuta si hay un cambio con respecto a la última ejecución de canalización programada correcta y no hay ninguna ejecución de canalización programada en curso.
true	false	La canalización se ejecuta según la programación cron.
true	true	La canalización se ejecuta según la programación cron.

Importante

Cuando always es true, la canalización se ejecuta según la programación cron, incluso cuando batch es true.

Variable Build.CronSchedule.DisplayName

Cuando se ejecuta una canalización debido a un desencadenador programado cron, la variable predefinida Build.CronSchedule.DisplayName contiene eldisplayName de la programación cron que desencadenó la ejecución de la canalización.

La canalización YAML puede contener varias programaciones cron y es posible que desee que la canalización ejecute diferentes fases o trabajos en función de la programación cron que se ejecuta. Por ejemplo, tiene una compilación nocturna y una compilación semanal, y quiere ejecutar una determinada fase solo durante la compilación nocturna. Puede usar la variable Build.CronSchedule.DisplayName en una condición de trabajo o fase para determinar si se debe ejecutar ese trabajo o fase.

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

Para ver más ejemplos, consulte schedules.cron ejemplos.

Clásico

Seleccione los días y las horas para ejecutar la compilación mediante el editor clásico.

Si el repositorio es Azure Repos Git, GitHub u otro Git, también puede especificar ramas que incluir y excluir. Si quiere usar caracteres comodín, escriba la especificación de la rama (por ejemplo, features/modules/*) y presione Entrar.

Ejemplos

YAML

En el ejemplo siguiente se definen dos programas:

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

La primera programación, Daily midnight build, ejecuta una canalización a medianoche todos los días, pero solo si el código ha cambiado desde la última ejecución programada correctamente para las ramas main y releases/*, excepto para las ramas de releases/ancient/*.

La segunda programación, Weekly Sunday build, ejecuta una canalización a mediodía los domingos, independientemente de que el código haya cambiado o no desde la última ejecución, para todas las ramas releases/*.

Nota:

La zona horaria de las programaciones cron es UTC, por lo que en estos ejemplos, la compilación de medianoche y la compilación de mediodía están a medianoche y mediodía en UTC.

Para más ejemplos, consulte Migración desde el editor clásico.

Clásico

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, que generan las siguientes compilaciones.

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

  

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

  

Ejemplo: Compilación nocturna con diferentes frecuencias

Azure Pipelines y Azure DevOps 2019 Server

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

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

  

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

  

Sintaxis cron

YAML

Cada expresión cron del desencadenador programado de Azure Pipelines es una expresión delimitada por espacios con cinco entradas en el orden siguiente. La expresión se incluye entre comillas simples '.

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

Campo	Valores aceptados
Minutos	De 0 a 59
Horas	De 0 a 23
Días	De 1 a 31
Meses	De 1 a 12, nombres completos en inglés, primeras tres letras de nombres en inglés
Días de la semana	De 0 a 6 (a partir del domingo), nombres completos en inglés, primeras tres letras de nombres en inglés

Los valores pueden tener los siguientes formatos.

Formato	Ejemplo	Descripción
Wildcard (Carácter comodín)	*	Coincide con todos los valores de este campo.
Un solo valor	5	Especifica un valor único para este campo.
Delimitado por comas.	3,5,6	Especifica varios valores para este campo. Se pueden combinar varios formatos, como 1,3-6.
Intervalos	1-3	Intervalo inclusivo de valores para este campo.
Intervalos	*/4 o 1-5/2	Intervalos que deben coincidir con este campo, como cada cuarto valor o el intervalo 1-5 con un intervalo de pasos de 2.

Ejemplo	Expresión Cron
Compilar todos los lunes, miércoles y viernes a las 18:00	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5o 0 18 * * 1-5/2
Compilación cada seis horas.	0 0,6,12,18 * * *, 0 */6 * * * o 0 0-18/6 * * *
Compilación cada seis horas a partir de las 9:00.	0 9,15,21 * * * o 0 9-21/6 * * *

Para más información sobre los formatos admitidos, consulte Expresión Crontab.

Clásico

Las programaciones clásicas se definen mediante un editor gráfico en lugar de una sintaxis cron. Para información sobre cómo definir programaciones clásicas, consulte Ejemplos.

Vista Ejecuciones programadas

YAML

Para ver una vista previa de las próximas compilaciones programadas, elija Ejecuciones programadas en el menú contextual de la página de detalles de la canalización.

Importante

La vista de ejecuciones programadas solo muestra las canalizaciones programadas para ejecutarse en un plazo de siete días a partir de la fecha actual. Si la programación cron tuviera un intervalo superior a 7 días y la siguiente ejecución estuviera programada para iniciarse después de siete días a partir de la fecha actual, no se mostrará en la vista de ejecuciones programadas.

Una vez creados o actualizados los desencadenadores programados, puede comprobarlos con esta vista.

En este ejemplo se muestran las ejecuciones programadas para la siguiente programación.

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

Las ventanas de Ejecuciones programadas muestran las horas convertidas en la zona horaria local establecida en el equipo que se usa para ir al portal de Azure DevOps. En este ejemplo se muestra una captura de pantalla tomada en la zona horaria EST.

Clásico

Para ver una vista previa de las próximas compilaciones programadas, elija Ejecuciones programadas en el menú contextual de la página de detalles de la canalización.

Una vez creados o actualizados los desencadenadores programados, puede comprobarlos con esta vista.

En ejecución aunque no haya 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, supongamos que ha programado una canalización para que se ejecute cada noche a las 21:00. 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 del viernes, la canalización no se ejecuta según lo programado durante el fin de semana.

YAML

Para forzar que una canalización se ejecute aunque no haya cambios en el código, puede usar la palabra clave always.

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

Clásico

Para configurar la canalización programada para compilar solo si se ha producido un cambio desde la última compilación, marque Programe compilaciones solo si ha cambiado el origen o la canalización.

Límites en el número de ejecuciones programadas en canalizaciones YAML

Existen ciertos límites en cuanto a la frecuencia con la que se puede programar la ejecución de una canalización. Estos límites se han establecido para evitar el uso indebido de los recursos de Azure Pipelines, en particular de los agentes hospedados en Microsoft. Los límites son:

• alrededor de 1000 ejecuciones por canalización por semana
• 10 ejecuciones por canalización por 15 minutos

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, que generan las siguientes compilaciones.

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

  

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

  

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, compilación diaria de India L-V 3:00 (UTC + 5:30), 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, es necesario restar 5 horas y 30 minutos de la hora de compilación deseada de las 3:00 para llegar a la hora UTC deseada para especificar para el desencadenador YAML.
• 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 en la zona horaria UTC + 5:30 en 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, compilación diaria de NC L-V 3:00 (UTC - 5), 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 sumar5 horas a la hora de compilación deseada de las 3:00 para llegar a la hora UTC deseada para especificar para el desencadenador YAML.
• 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: como nuestras conversiones de zona horaria no abarcan varios días de la semana para la 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.

Importante

Las zonas horarias UTC de los desencadenadores programados de YAML no tienen en cuenta el horario de verano.

Sugerencia

Con los días de la semana de tres letras, si se quiere tener un intervalo de varios días a partir del domingo (Dom), Dom debe considerarse el primer día de la semana; por ejemplo, para una programación de medianoche EST, de jueves a domingo, la sintaxis cron es 0 5 * * Sun,Thu-Sat.

Ejemplo: Compilación nocturna con diferentes frecuencias

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

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

  

• Todos los domingos a las 3:00 UTC, compile la rama releases/lastversion, 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, compilación diaria L-V 3:00 (UTC), la sintaxis cron es 0 3 * * Mon-Fri.

• Minutos y horas: 0 3: se asigna a 3:00 AM UTC. Puesto 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: como no hay ninguna conversión de zona horaria, los días de la semana se asignan 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, compilación de la versión más reciente semanal del domingo a las 3:00 (UTC), la sintaxis cron es 0 3 * * Sun.

• Minutos y horas: 0 3: se asigna a 3:00 AM UTC. Puesto 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: como nuestras conversiones de zona horaria no abarcan varios días de la semana para la 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 tanto si se ha actualizado el código fuente como si no.

Preguntas más frecuentes

• Quiero que mi canalización se ejecute solo 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 ha ejecutado. ¿Qué ha ocurrido?
• Mis programaciones de YAML funcionaban bien. Sin embargo, han dejado de funcionar. ¿Cómo se puede depurar este error?
• 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 está ejecutando en ese momento. ¿Por qué?
• Las programaciones definidas en la canalización de YAML funcionan para una rama, pero no para la otra. ¿Cómo puedo corregirlo?

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

Si quiere 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, tendrá que deshabilitar explícitamente los desencadenadores de CI y PR predeterminados en la canalización.

Para deshabilitar los desencadenadores de CI y PR predeterminados, agregue las siguientes instrucciones a la canalización de YAML y compruebe que no se hayan 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 ha ejecutado. ¿Qué ha ocurrido?

• Compruebe las siguientes ejecuciones que Azure Pipelines tiene programadas 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 días siguientes. Si esto no cumple sus expectativas, es probable 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 aprender a 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 antes había algún problema al leer las programaciones del archivo YAML, debería haberse corregido.

• 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 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. Aprenda a invalidar este comportamiento.

Mis programaciones de YAML funcionaban bien. Sin embargo, han dejado de funcionar. ¿Cómo se puede depurar este error?

• Si no especificó always:true, la canalización no se programará a menos que haya actualizaciones 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 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 tiene programadas para la canalización. Para encontrar estas ejecuciones, seleccione la acción Ejecuciones programadas en la canalización. Si no ve las programaciones esperadas, realice un pequeño cambio trivial en el archivo YAML e inserte la actualización en el repositorio. Esto debería volver a sincronizar las programaciones.

• Si usa GitHub para almacenar el código, es posible que GitHub haya limitado Azure Pipelines al intentar 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 aunque no haya 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 aunque no haya actualizado el código fuente.

• Azure Pipelines comprueba primero si hay alguna actualización en el código. Si Azure Pipelines no puede acceder al repositorio u 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 programa una nueva compilación o no, Azure DevOps busca la última compilación programada completamente correcta. 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, aunque el código no haya cambiado.

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

• El panel Ejecuciones programadas muestra todas las programaciones posibles. Sin embargo, es posible que no se ejecute realmente a menos que se hayan realizado actualizaciones reales en el código. Para forzar que una programación se ejecute siempre, 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.

Las programaciones definidas en la canalización de YAML funcionan para una rama, pero no para la otra. ¿Cómo puedo corregirlo?

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 la programación cron definida en ella y las inclusiones de rama correctas para la programación. El archivo YAML de la rama features/X debe tener el siguiente schedule en este ejemplo:

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

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