Configuración de programaciones para canalizaciones
Nota
En Microsoft Team Foundation Server (TFS) 2018 y versiones anteriores, las canalizaciones de compilación y versión se denominan definiciones, las ejecuciones se denominan compilaciones, las conexiones de servicio se denominan puntos de conexión de servicio, las fases se denominan entornos y los trabajos se denominan fases.
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 crear una solicitud de extracción o insertar en una rama. Para obtener información sobre el uso de desencadenadores basados en eventos, vea 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 deCI),cuando se realiza una solicitud de extracción(desencadenadorde SOLICITUD) y una compilación nocturna (desencadenador programado). Si desea compilar la canalización solo según una programación y no en respuesta a desencadenadores basados en eventos, asegúrese de que la canalización no tiene ningún otro desencadenador habilitado. Por ejemplo, las canalizaciones YAML de un repositorio GitHub tienen desencadenadores de CI y desencadenadores de solicitud habilitados de forma predeterminada. Para obtener información sobre cómo deshabilitar los desencadenadores predeterminados, consulte Desencadenadores en Azure Pipelines vaya a la sección que cubre el tipo de repositorio.
Desencadenadores programados
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 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 de YAML, debe quitar los desencadenadores programados definidos en la interfaz de usuario de configuración de canalización. Una vez que se quitan todos los desencadenadores programados de la interfaz de usuario, se debe realizar una inserción para que los desencadenadores programados de YAML empiecen a evaluarse.
Para eliminar los desencadenadores programados de la interfaz de usuario de una canalización de YAML, consulte Configuración de la interfaz de usuario 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.
Las canalizaciones programadas en YAML tienen las siguientes restricciones.
- La zona horaria para las programaciones cron es UTC.
- Si especifica una cláusula sin una cláusula para , equivale a
excludeespecificar en la cláusulaincludebranches*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 desencadenadores programados
Los desencadenadores programados se evalúan para una rama cuando se producen los siguientes eventos.
- Se crea una canalización.
- El archivo YAML de una canalización se actualiza, 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 otro archivo YAML. Este cambio solo actualiza la rama predeterminada y, por tanto, solo recoge las programaciones en el archivo YAML actualizado para la rama predeterminada. Si alguna otra rama combina posteriormente la rama predeterminada, por ejemplo , los desencadenadores programados del archivo YAML al que se hace referencia recientemente se
git pull origin mainevalúan para esa rama. - Se crea una nueva rama.
Una vez que se produce 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 contenidos en el 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 particular.
Por ejemplo, se crea una canalización con la siguiente programación y esta versión del archivo YAML se registra en la main rama. Esta programación compila la main rama 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 . Se leen los desencadenadores programados del archivo YAML de la nueva rama y, como no hay ninguna coincidencia con la rama, no se realizan cambios en las compilaciones programadas y la rama no se compila mediante un desencadenador new-featurenew-feature programado.
Si se agrega a la lista y este cambio se inserta en la rama, se lee el archivo YAML y, como ahora está en la lista de ramas, se agrega una compilación programada para la new-featurebranchesnew-featurenew-featurenew-feature rama.
# 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 una rama denominada se crea a partir de y, a continuación, se agrega a los filtros de rama en el archivo YAML de la rama, pero no en la releasemain rama recién releasemainrelease 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 se agregó a los filtros de rama de la rama, pero no a los filtros de rama de la rama, la rama no se basará releasemain en esa releasereleaserelease programación. Solo cuando la rama se agrega a los filtros de rama en el archivo YAML de la rama de características, la compilación programada se feature agregará al feature programador.
Las compilaciones programadas no se admiten en la sintaxis YAML Azure DevOps Server 2019. Después de crear la canalización de compilación de YAML, puede usar la configuración de canalización para especificar un desencadenador programado.
Las canalizaciones yaml no están disponibles en TFS.
Ejemplos
En el ejemplo siguiente se definen dos programaciones:
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, Compilacióndiaria a medianoche, ejecuta una canalización a medianoche todos los días, pero solo si el código ha cambiado desde la última ejecución programada correcta, para y todas las ramas, excepto las de releases/*releases/ancient/* .
La segunda programación, Compilaciónsemanal del domingo, ejecuta una canalización a las 12:00 del domingo, independientemente de si el código ha cambiado o no desde la última ejecución, para todas las ramas.
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 son a medianoche y a mediodía en UTC.
Para obtener más ejemplos, vea Migración desde el editor clásico.
Las compilaciones programadas no se admiten en la sintaxis YAML Azure DevOps Server 2019. Después de crear la canalización de compilación de YAML, puede usar la configuración de canalización para especificar un desencadenador programado.
Las canalizaciones yaml no están disponibles en TFS.
Sintaxis cron
Cada Azure Pipelines de desencadenador programado cron es una expresión delimitada por espacios con cinco entradas en el orden siguiente.
mm HH DD MM DW
\ \ \ \ \__ Days of week
\ \ \ \____ Months
\ \ \______ Days
\ \________ Hours
\__________ Minutes
| Campo | Valores aceptados |
|---|---|
| Minutos | Del 0 al 59 |
| Horas | Del 0 al 23 |
| Días | Del 1 al 31 |
| Meses | De 1 a 12, nombres completos en inglés, tres primeras letras de nombres en inglés |
| Días de la semana | De 0 a 6 (a partir del domingo), nombres completos en inglés, tres primeras 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 se van a coincidir para este campo, como cada cuatro 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 6:00 p. m. | 0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5o 0 18 * * 1-5/2 |
| Compilación cada 6 horas | 0 0,6,12,18 * * *, 0 */6 * * * o 0 0-18/6 * * * |
| Compilación cada 6 horas a partir de las 9:00 a. m. | 0 9,15,21 * * * o 0 9-21/6 * * * |
Para obtener más información sobre los formatos admitidos, vea Expresión crontab.
Las compilaciones programadas no se admiten en la sintaxis YAML Azure DevOps Server 2019. Después de crear la canalización de compilación de YAML, puede usar la configuración de canalización para especificar un desencadenador programado.
Las canalizaciones yaml no están disponibles en TFS.
Vista ejecuciones programadas
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 para la canalización.
Después de crear o actualizar los desencadenadores programados, puede comprobarlos mediante esta vista.
En este ejemplo se muestran las ejecuciones programadas para la programación siguiente.
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
Las ventanas Ejecuciones programadas muestran las horas convertida en el conjunto de zonas horarias local en el equipo que se usa para ir al portal Azure DevOps programación. En este ejemplo se muestra una captura de pantalla realizada en la zona horaria est.
Las compilaciones programadas no se admiten en la sintaxis YAML Azure DevOps Server 2019. Después de crear la canalización de compilación de YAML, puede usar la configuración de canalización para especificar un desencadenador programado.
Las canalizaciones yaml no están disponibles en TFS.
Ejecución incluso cuando no hay cambios en el código
Nota
Las compilaciones programadas siempre se ejecutan según la programación, independientemente de los cambios de código en TFS 2018.1 y las inferiores.
De forma predeterminada, la canalización no se ejecuta como programada si no se ha producido ningún cambio 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 todas las 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 se realiza ningún cambio en el código. Si no ha habido ningún cambio de código desde la ejecución programada el viernes, la canalización no se ejecuta según lo programado durante el fin de semana.
Para forzar la ejecución de una canalización incluso cuando no haya cambios en el código, puede usar la palabra always clave .
schedules:
- cron: ...
...
always: true
Las compilaciones programadas no se admiten en la sintaxis YAML en esta versión de Azure DevOps Server. Después de crear la canalización de compilación de YAML, puede usar la configuración de canalización para especificar un desencadenador programado.
Las canalizaciones yaml no están disponibles en TFS.
Límites en el número de ejecuciones programadas
Hay 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 Azure Pipelines recursos, especialmente los agentes hospedados por Microsoft. Este límite es de aproximadamente 1000 ejecuciones por canalización por semana.
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 distintas 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 y viernes a las 3:00 a. m. (UTC + 5:30 zona horaria), cree ramas que cumplan los criterios de filtro
features/india/*de rama.
Todos los lunes y viernes a las 3:00 a. m. (UTC - 5:00 zona horaria), cree ramas que cumplan los criterios de filtro
features/nc/*de 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 AM (UTC + 5:30) India daily build, la sintaxis cron ( ) es 30 21 * * Sun-Thu .
- Minutos y
30 21horas: se asigna a21:30 UTC(9:30 PM UTC). Puesto que la zona horaria especificada en el editor clásico es UTC + 5:30, es necesario restar 5 horas y 30 minutos del tiempo de compilación deseado de las 3:00 a. m. 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: 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
Sun-Thuhora UTC. También podríamos especificar los días de la semana como0-4o0,1,2,3,4.
En la segunda programación, M-F 3:00 AM (UTC - 5) NC daily build, la sintaxis cron es .
- Minutos y horas:
0 8se asigna a8:00 AM UTC. Puesto 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 a. m. 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: como nuestras conversiones de zona horaria no abarcan varios días de la semana para la programación deseada, no es necesario realizar
Mon-Frininguna conversión aquí. También podríamos especificar los días de la semana como1-5o1,2,3,4,5.
Importante
Las zonas horarias UTC de los desencadenadores programados de YAML no tienen en cuenta el horario de verano.
Sugerencia
Al usar 3 días de la semana y desear un intervalo de varios días hasta el sol, Sun 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 distintas frecuencias
En este ejemplo, el desencadenador programado del editor clásico tiene dos entradas, lo que genera las siguientes compilaciones.
Todos los lunes y viernes a las 3:00 a. m. UTC, cree ramas que cumplan los criterios de filtro
mainreleases/*de rama y .
Todos los domingos a las 3:00 a. m. UTC, compile la rama, incluso si el origen o la canalización
releases/lastversionno 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, M-F 3:00 AM (UTC) compilacióndiaria , la sintaxis cron es .
- Minutos y horas:
0 3se asigna a3: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 , - - porque no hay ninguna conversión de zona horaria, los días de la semana se asignan directamente desde
Mon-Frila programación del editor clásico. También podríamos especificar los días de la semana como1,2,3,4,5.
En la segunda programación, domingo a las 3:00 a. m. (UTC) compilaciónde la versión más reciente semanal , la sintaxis cron es .
- Minutos y horas:
0 3se asigna a3: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: como nuestras conversiones de zona horaria no abarcan varios días de la semana para la programación deseada, no es necesario realizar
Sunninguna conversión aquí. También podríamos especificar los días de la semana como0. - También se
always: trueespecifica, ya que esta compilación está programada para ejecutarse independientemente de si se ha actualizado o no el código fuente.
Preguntas más frecuentes
- He definido una programación en el archivo YAML. Pero no se ha ejecutado. ¿Qué ha ocurrido?
- Mis programaciones de YAML funcionaban bien. Pero ahora han dejado de funcionar. Cómo 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é?
- Las programaciones definidas en la canalización de YAML funcionan para una rama, pero no para la otra. ¿Cómo puedo corregirlo?
He definido una programación en el archivo YAML. Pero no se ha ejecutado. ¿Qué ha ocurrido?
Compruebe las siguientes ejecuciones que Azure Pipelines ha programado para la canalización. Puede encontrarlos seleccionando 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 satisface sus expectativas, es probable que haya escrito erróneamente la programación cron o que no tenga la programación definida en la rama correcta. Lea el tema anterior para saber cómo configurar programaciones. Vuelva a evaluar la sintaxis cron. Todas las horas de las programaciones cron están en formato UTC.
Realice un pequeño cambio trivial en el archivo YAML e inscútela en el repositorio. Si hubo algún problema al leer las programaciones del archivo YAML anteriormente, debería solucionarse ahora.
Si tiene programaciones definidas en la interfaz de usuario, no se respetan las programaciones de YAML. Asegúrese de que no tiene programaciones 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 se pueden programar para una canalización. Obtenga más información sobre los límites.
Si no hay ningún cambio en el código, Azure Pipelines iniciar nuevas ejecuciones. Obtenga información sobre cómo invalidar este comportamiento.
Mis programaciones de YAML funcionaban bien. Pero ahora han dejado de funcionar. Cómo Depurar esto?
Si no especificó , la canalización no se programará a menos que haya
always:trueactualizaciones realizadas en el código. Compruebe si ha habido algún cambio 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 programaciones adicionales 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. Puede encontrarlos seleccionando 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 insertar 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 Azure Pipelines haya estado limitada por GitHub 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 incluso si no hay 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 usada 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 u obtener esta información, iniciará una ejecución programada de todos modos o creará una ejecución con error para indicar que no puede acceder al repositorio. Si observa que se ha creado una ejecución y que se ha generado un error inmediatamente, es probable que este sea el motivo. Se trata de una compilación ficticia que le permite saber Azure Pipelines no puede acceder al repositorio.
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 no se ejecute realmente a menos que haya 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 de YAML o 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 se programe una canalización para una rama determinada, por ejemplo, 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 features/X programación. features/X El archivo YAML de features/X la rama debe tener lo siguiente en este ejemplo:
schedules:
- cron: "0 12 * * 0" # replace with your schedule
branches:
include:
- features/X
Para obtener más información, vea Consideraciones de rama para desencadenadores programados.