Configurer des planifications pour les pipelines

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

Azure Pipelines fournit plusieurs types de déclencheurs pour configurer le démarrage de votre pipeline.

• Les déclencheurs planifiés démarrent votre pipeline en fonction d’une planification, comme une build nocturne. Cet article fournit des conseils sur l’utilisation de déclencheurs planifiés pour exécuter vos pipelines en fonction d’une planification.
• Les déclencheurs basés sur des événements démarrent votre pipeline en réponse à des événements, comme la création d’une demande de tirage ou l’envoi vers une branche. Pour plus d’informations sur l’utilisation de déclencheurs basés sur des événements, consultez Déclencheurs dans Azure Pipelines.

Vous pouvez combiner des déclencheurs planifiés et basés sur des événements dans vos pipelines, par exemple pour valider la build chaque fois qu’un envoi est effectué (déclencheur CI), lorsqu’une demande de tirage est effectuée (déclencheur PR) et pour une build nocturne (déclencheur planifié). Si vous souhaitez générer votre pipeline uniquement selon une planification et non en réponse à des déclencheurs basés sur des événements, assurez-vous que votre pipeline n’a pas d’autres déclencheurs activés. Par exemple, les pipelines YAML d’un dépôt GitHub ont des déclencheurs CI et des déclencheurs de demande de tirage activés par défaut. Pour plus d’informations sur la désactivation des déclencheurs par défaut, consultez Déclencheurs dans Azure Pipelines et accédez à la section qui couvre votre type de dépôt.

Déclencheurs planifiés

YAML

Important

Les déclencheurs planifiés définis à l’aide de l’interface utilisateur des paramètres de pipeline sont prioritaires sur les déclencheurs planifiés YAML.

Si votre pipeline YAML comporte à la fois des déclencheurs planifiés YAML et des déclencheurs planifiés définis par l’interface utilisateur, seuls les déclencheurs planifiés définis par l’interface utilisateur sont exécutés. Pour exécuter les déclencheurs planifiés définis par YAML dans votre pipeline YAML, vous devez supprimer les déclencheurs planifiés définis dans l’interface utilisateur des paramètres de pipeline. Une fois que tous les déclencheurs planifiés de l’interface utilisateur ont été supprimés, une poussée doit être effectuée pour que les déclencheurs planifiés YAML commencent à être évalués.

Pour supprimer des déclencheurs planifiés par l’interface utilisateur d’un pipeline YAML, consultez Les paramètres de l’interface utilisateur remplacent les déclencheurs planifiés YAML.

Les déclencheurs planifiés configurent un pipeline pour qu’il s’exécute selon une planification définie à l’aide de la syntaxe 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

Les pipelines planifiés dans YAML ont les contraintes suivantes.

• Le fuseau horaire des planifications cron est UTC.
• Si vous spécifiez une clause exclude sans clause include pour branches, cela équivaut à spécifier * dans la clause include.
• Vous ne pouvez pas utiliser de variables de pipeline lors de la spécification de planifications.
• Si vous utilisez des modèles dans votre fichier YAML, les planifications doivent être spécifiées dans le fichier YAML principal et non dans les fichiers de modèle.

Considérations relatives aux branches pour les déclencheurs planifiés

Les déclencheurs planifiés sont évalués pour une branche lorsque les événements suivants se produisent.

• Un pipeline est créé.
• Le fichier YAML d’un pipeline est mis à jour, soit à partir d’un envoi, soit en le modifiant dans l’éditeur de pipeline.
• Le chemin du fichier YAML d’un pipeline est mis à jour pour référencer un autre fichier YAML. Cette modification met uniquement à jour la branche par défaut et ne sélectionne donc que les planifications dans le fichier YAML mis à jour pour la branche par défaut. Si d’autres branches fusionnent par la suite la branche par défaut, par exemple git pull origin main, les déclencheurs planifiés à partir du fichier YAML nouvellement référencé sont évalués pour cette branche.
• Une nouvelle branche est créée.

Une fois que l’un de ces événements se produit dans une branche, toutes les exécutions planifiées pour cette branche sont ajoutées, si cette branche correspond aux filtres de branche pour les déclencheurs planifiés contenus dans le fichier YAML de cette branche.

Important

Les exécutions planifiées pour une branche sont ajoutées uniquement si la branche correspond aux filtres de branche pour les déclencheurs planifiés dans le fichier YAML de cette branche particulière.

Par exemple, un pipeline est créé avec la planification suivante, et cette version du fichier YAML est archivée dans la branche main. Cette planification génère quotidiennement la branche main.

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

Ensuite, une nouvelle branche est créée en fonction de main, nommée new-feature. Les déclencheurs planifiés à partir du fichier YAML dans la nouvelle branche sont lus et, comme il n’existe aucune correspondance pour la branche new-feature, aucune modification n’est apportée aux builds planifiées et la branche new-feature n’est pas générée à l’aide d’un déclencheur planifié.

Si new-feature est ajouté à la liste branches et que cette modification est envoyée à la branche new-feature, le fichier YAML est lu et, étant donné que new-feature se trouve désormais dans la liste des branches, une build planifiée est ajoutée pour la branche new-feature.

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

Considérez maintenant qu’une branche nommée release est créée en fonction de main, puis que release est ajouté aux filtres de branche dans le fichier YAML dans la branche main, mais pas dans la branche release nouvellement créée.

# 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

Étant donné que release a été ajouté aux filtres de branche dans la branche main, mais pas aux filtres de branche dans la branche release, la branche release ne sera pas basée sur cette planification. Ce n’est que lorsque la branche release est ajoutée aux filtres de branche dans le fichier YAML dans la branche release que la build planifiée sera ajoutée au planificateur.

Considérations relatives aux lots pour les déclencheurs de planification

La propriété batch permet de configurer l'exécution du pipeline si l'exécution précédemment programmée est en cours ; la valeur par défaut est false. Cela, quelle que soit la version du dépôt de pipeline.

Les tableaux suivants décrivent la manière dont always et batch interagissent.

Toujours	Batch	Comportement
false	false	Le pipeline ne s'exécute que s'il y a un changement par rapport à la dernière exécution programmée réussie du pipeline.
false	true	Le pipeline s’exécute uniquement s’il y a une modification par rapport à la dernière exécution planifiée réussie du pipeline, et s’il n’y a pas d’exécution de pipeline planifiée en cours.
true	false	Le pipeline s’exécute selon la planification cron.
true	true	Le pipeline s’exécute selon la planification cron.

Important

Quand always est true, le pipeline s’exécute conformément à la planification cron, même si batch est true.

Variable Build.CronSchedule.DisplayName

Lorsqu’un pipeline s’exécute en raison d’un déclencheur de planification cron, la variable prédéfinie Build.CronSchedule.DisplayName contient le displayName de la planification cron qui a déclenché l’exécution du pipeline.

Votre pipeline YAML peut contenir plusieurs planifications cron, et vous pouvez vouloir que votre pipeline exécute différentes étapes ou tâches en fonction de la planification cron qui s'exécute. Par exemple, vous disposez d’une build nocturne et d’une build hebdomadaire, et vous souhaitez exécuter une certaine étape uniquement pendant la build nocturne. Vous pouvez utiliser la variable Build.CronSchedule.DisplayName dans une condition de travail ou d’index pour déterminer s’il faut exécuter ce travail ou cet index.

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

Pour plus d’exemples, voir schedules.cron examples.

Classique

Sélectionnez les jours et heures où vous souhaitez exécuter la build à l’aide de l’éditeur classique.

Si votre dépôt est Azure Repos Git, GitHub ou Autre Git, vous pouvez également spécifier des branches à inclure et à exclure. Si vous souhaitez utiliser des caractères génériques, tapez la spécification de branche (par exemple, features/modules/*), et appuyez sur Entrée.

Exemples

YAML

L’exemple suivant définit deux planifications :

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 première planification, Build quotidienne à minuit, exécute un pipeline à minuit tous les jours, mais uniquement si le code a changé depuis la dernière exécution planifiée réussie, pour main et toutes les branches releases/*, à l’exception des branches sous releases/ancient/*.

La deuxième planification, Build hebdomadaire le dimanche, exécute un pipeline à midi le dimanche, que le code ait changé ou non depuis la dernière exécution, pour toutes les branches releases/*.

Notes

Le fuseau horaire des planifications cron est UTC. Ainsi, dans ces exemples, la build de minuit et la build de midi sont effectuées à minuit et midi en UTC.

Pour plus d’exemples, consultez Migration à partir de l’éditeur classique.

Classique

Exemple : build nocturne de dépôt Git sur plusieurs fuseaux horaires

Dans cet exemple, le déclencheur planifié de l’éditeur classique a deux entrées, qui produisent les builds suivantes.

• Tous les lundis - vendredis à 03h00 (UTC + 5h30), générer des branches qui répondent aux critères de filtre de branche features/india/*

  

• Tous les lundis - vendredis à 03h00 (UTC - 5h), générer des branches qui répondent aux critères de filtre de branche features/nc/*

  

Exemple : build nocturne avec différentes fréquences

Azure Pipelines et Azure DevOps 2019 Server

Dans cet exemple, le déclencheur planifié de l’éditeur classique a deux entrées, ce qui produit les builds suivantes.

• Tous les lundis - vendredis à 3h00 UTC, créez des branches qui répondent aux critères de filtre de branche main et releases/*

  

• Tous les dimanches à 3h00 UTC, créez la branche releases/lastversion, même si la source ou le pipeline n’a pas changé

  

Syntaxe cron

YAML

Chaque expression cron de déclencheur planifié Azure Pipelines est une expression délimitée par des espaces avec cinq entrées dans l’ordre suivant. L’expression est placée entre guillemets simples (').

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

Champ	Valeurs acceptées
Minutes	0 à 59
Heures	–0 à 23
Jours	–1 à 31
Mois	1 à 12, noms anglais complets, trois premières lettres des noms anglais
Jours de la semaine	0 à 6 (à compter du dimanche), noms complets en anglais, trois premières lettres des noms anglais

Les valeurs peuvent être dans les formats suivants.

Format	Exemple	Description
Caractère générique	*	Correspond à toutes les valeurs de ce champ
Valeur unique	5	Spécifie une valeur unique pour ce champ
Séparé par un point-virgule	3,5,6	Spécifie plusieurs valeurs pour ce champ. Plusieurs formats peuvent être combinés, comme 1,3-6
Plages	1-3	Plage inclusive de valeurs pour ce champ
Intervalles	*/4 ou 1-5/2	Intervalles à mettre en correspondance pour ce champ, comme chaque quatrième valeur ou la plage de 1 à 5 avec un intervalle de pas de 2

Exemple	Expression CRON
Build tous les lundis, mercredis et vendredis à 18h00	0 18 * * Mon,Wed,Fri, 0 18 * * 1,3,5ou 0 18 * * 1-5/2
Générer toutes les 6 heures	0 0,6,12,18 * * *, 0 */6 * * * ou 0 0-18/6 * * *
Build toutes les 6 heures à partir de 9h00	0 9,15,21 * * * ou 0 9-21/6 * * *

Pour plus d’informations sur les formats pris en charge, consultez Expression Crontab.

Classique

Les planifications classiques sont définies à l’aide d’un éditeur graphique au lieu de la syntaxe cron. Pour plus d’informations sur la définition de planifications classiques, consultez Exemples.

Vue Exécutions planifiées

YAML

Pour afficher un aperçu des builds planifiées à venir, choisissez Exécutions planifiées dans le menu contextuel de la page des détails de votre pipeline.

Important

La vue Exécutions planifiées affiche uniquement les pipelines planifiés pour s’exécuter dans les sept jours à compter de la date actuelle. Si votre planification cron a un intervalle supérieur à 7 jours et que l’exécution suivante est planifiée pour démarrer après sept jours à partir de la date actuelle, elle ne s’affiche pas dans la vue Exécutions planifiées.

Après avoir créé ou mis à jour vos déclencheurs planifiés, vous pouvez les vérifier à l’aide de la vue Exécution planifiée.

Cet exemple montre comment afficher les exécutions planifiées pour la planification suivante.

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

Les fenêtres Exécutions planifiées affichent les heures converties en fuseau horaire local défini sur l’ordinateur utilisé pour accéder au portail Azure DevOps. Cet exemple montre comment afficher une capture d’écran effectuée dans le fuseau horaire EST.

Remarque

Si vous mettez à jour la planification d'un pipeline en cours d'exécution, la vue Exécutions planifiées n'est pas mise à jour avec la nouvelle planification tant que le pipeline en cours d'exécution n'est pas terminé.

Classique

Pour afficher un aperçu des builds planifiées à venir, choisissez Exécutions planifiées dans le menu contextuel de la page des détails de votre pipeline.

Après avoir créé ou mis à jour vos déclencheurs planifiés, vous pouvez les vérifier à l’aide de cette vue.

Exécution même en l’absence de modification du code

Par défaut, votre pipeline ne s’exécute pas comme prévu s’il n’y a eu aucune modification du code depuis la dernière exécution planifiée réussie. Par exemple, supposons que vous planifiez l’exécution d’un pipeline tous les soirs à 21h00. Pendant les jours de la semaine, vous envoyez diverses modifications à votre code. Le pipeline s’exécute conformément à la planification. Pendant les week-ends, vous n’apportez aucune modification à votre code. S’il n’y a pas eu de modifications de code depuis l’exécution planifiée le vendredi, le pipeline ne s’exécute pas comme prévu pendant le week-end.

YAML

Pour forcer l’exécution d’un pipeline même en l’absence de modification du code, vous pouvez utiliser le mot clé always.

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

Classique

Pour configurer le pipeline planifié pour qu’il génère uniquement s’il y a eu une modification depuis la dernière build, vérifiez Planifier uniquement les builds si la source ou le pipeline a changé.

Limites du nombre d’exécutions planifiées dans les pipelines YAML

Il existe certaines limites quant à la fréquence à laquelle vous pouvez planifier l’exécution d’un pipeline. Ces limites ont été mises en place pour éviter toute utilisation abusive des ressources Azure Pipelines, en particulier les agents hébergés par Microsoft. Les limites sont les suivantes :

• environ 1 000 exécutions par pipeline et par semaine
• 10 exécutions par pipeline toutes les 15 minutes

Migration à partir de l’éditeur classique

Les exemples suivants vous montrent comment migrer vos planifications de l’éditeur classique vers YAML.

• Exemple : build nocturne de dépôt Git sur plusieurs fuseaux horaires
• Exemple : build nocturne avec différentes fréquences

Exemple : build nocturne de dépôt Git sur plusieurs fuseaux horaires

Dans cet exemple, le déclencheur planifié de l’éditeur classique a deux entrées, ce qui produit les builds suivantes.

• Tous les lundis - vendredis à 03h00 (UTC + 5h30), générer des branches qui répondent aux critères de filtre de branche features/india/*

  

• Tous les lundis - vendredis à 03h00 (UTC - 5h), générer des branches qui répondent aux critères de filtre de branche features/nc/*

  

Le déclencheur planifié YAML équivalent est le suivant :

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

Dans la première planification, Build quotidienne pour l’Inde M-F 3:00 AM (UTC + 5:30), la syntaxe cron (mm HH DD MM DW) est 30 21 * * Sun-Thu.

• Minutes et heures - 30 21 - Mappé sur 21:30 UTC (9:30 PM UTC). Étant donné que le fuseau horaire spécifié dans l’éditeur classique est UTC + 5:30, nous devons soustraire 5 heures et 30 minutes de l’heure de build souhaitée de 3:00 AM pour arriver à l’heure UTC souhaitée à spécifier pour le déclencheur YAML.
• Les jours et les mois sont spécifiés en tant que caractères génériques, car cette planification ne spécifie pas de s’exécuter uniquement lors de certains jours du mois ou d’un mois spécifique.
• Jours de la semaine - Sun-Thu - en raison de la conversion de fuseau horaire, pour que nos builds s’exécutent à 3:00 AM dans le fuseau horaire UTC + 5:30 en Inde, nous devons spécifier leur démarrage le jour précédent en heure UTC. Nous pouvons également spécifier les jours de la semaine comme 0-4 ou 0,1,2,3,4.

Dans la deuxième planification, Build quotidienne NC M-F 3:00 AM (UTC - 5), la syntaxe cron est 0 8 * * Mon-Fri.

• Minutes et heures - 0 8 - Mappé sur 8:00 AM UTC. Étant donné que le fuseau horaire spécifié dans l’éditeur classique est UTC - 5:00, nous devons ajouter 5 heures à partir de l’heure de build souhaitée de 3:00 AM pour arriver à l’heure UTC souhaitée à spécifier pour le déclencheur YAML.
• Les jours et les mois sont spécifiés en tant que caractères génériques, car cette planification ne spécifie pas de s’exécuter uniquement lors de certains jours du mois ou d’un mois spécifique.
• Jours de la semaine - Mon-Fri - étant donné que nos conversions de fuseau horaire ne s’étendent pas sur plusieurs jours de la semaine pour notre planification souhaitée, nous n’avons pas besoin d’effectuer une conversion ici. Nous pouvons également spécifier les jours de la semaine comme 1-5 ou 1,2,3,4,5.

Important

Les fuseaux horaires UTC dans les déclencheurs planifiés YAML ne comptent pas l’heure d’été.

Conseil

Lorsque vous utilisez 3 lettres pour les jours de la semaine et que vous souhaitez une période de plusieurs jours jusqu’à dimanche, dimanche doit être considéré comme le premier jour de la semaine. Par exemple, pour un horaire de minuit EST, du jeudi au dimanche, la syntaxe cron est 0 5 * * Sun,Thu-Sat.

Exemple : build nocturne avec différentes fréquences

Dans cet exemple, le déclencheur planifié de l’éditeur classique a deux entrées, ce qui produit les builds suivantes.

• Tous les lundis - vendredis à 3h00 UTC, créez des branches qui répondent aux critères de filtre de branche main et releases/*

  

• Tous les dimanches à 3h00 UTC, créez la branche releases/lastversion, même si la source ou le pipeline n’a pas changé

  

Le déclencheur planifié YAML équivalent est le suivant :

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

Dans la première planification, M-F 3:00 AM (UTC), la syntaxe cron est 0 3 * * Mon-Fri.

• Minutes et heures - 0 3 - Mappé sur 3:00 AM UTC. Étant donné que le fuseau horaire spécifié dans l’éditeur classique est UTC, nous n’avons pas besoin d’effectuer de conversions de fuseau horaire.
• Les jours et les mois sont spécifiés en tant que caractères génériques, car cette planification ne spécifie pas de s’exécuter uniquement lors de certains jours du mois ou d’un mois spécifique.
• Jours de la semaine - Mon-Fri - étant donné qu’il n’y a pas de conversion de fuseau horaire, les jours de la semaine sont mappés directement à partir de la planification de l’éditeur classique. Nous pouvons également spécifier les jours de la semaine comme 1,2,3,4,5.

Dans la deuxième planification, Build hebdomadaire de la version la plus récente le dimanche à 3:00 AM (UTC), la syntaxe cron est 0 3 * * Sun.

• Minutes et heures - 0 3 - Mappé sur 3:00 AM UTC. Étant donné que le fuseau horaire spécifié dans l’éditeur classique est UTC, nous n’avons pas besoin d’effectuer de conversions de fuseau horaire.
• Les jours et les mois sont spécifiés en tant que caractères génériques, car cette planification ne spécifie pas de s’exécuter uniquement lors de certains jours du mois ou d’un mois spécifique.
• Jours de la semaine - Sun - étant donné que nos conversions de fuseau horaire ne s’étendent pas sur plusieurs jours de la semaine pour notre planification souhaitée, nous n’avons pas besoin d’effectuer une conversion ici. Nous pouvons également spécifier les jours de la semaine comme 0.
• Nous spécifions également always: true, étant donné que cette build est planifiée pour s’exécuter, que le code source ait été mis à jour ou non.

FAQ

• Je veux que mon pipeline s’exécute uniquement selon la planification et pas quand quelqu’un envoie une modification à une branche
• J’ai défini une planification dans le fichier YAML. Mais elle n’a pas été exécutée. Que s’est-il passé ?
• Mes plannings YAML fonctionnaient correctement. Mais ils ont cessé de travailler maintenant. Comment puis-je corriger cette erreur ?
• Mon code n’a pas changé, mais une build planifiée est déclenchée. Pourquoi ?
• Je vois l’exécution planifiée dans le panneau Exécutions planifiées. Toutefois, elle ne s’exécute pas à ce moment-là. Pourquoi ?
• Les planifications définies dans le pipeline YAML fonctionnent pour une branche, mais pas pour l’autre. Comment la corriger ?

Je veux que mon pipeline s’exécute uniquement selon la planification et pas quand quelqu’un envoie une modification à une branche

Si vous souhaitez que votre pipeline s’exécute uniquement selon la planification, et non pas lorsque quelqu’un envoie (push) une modification à une branche ou fusionne une modification dans la branche primaire, vous devez désactiver explicitement les déclencheurs CI et PR par défaut sur le pipeline.

Pour désactiver les déclencheurs CI et PR par défaut, ajoutez les instructions suivantes à votre pipeline YAML et vérifiez que vous n’avez pas remplacé les déclencheurs de pipeline YAML par des déclencheurs d’interface utilisateur.

trigger: none
pr: none

Pour plus d’informations, consultez définition pr et définition de déclencheur.

J’ai défini une planification dans le fichier YAML. Mais elle n’a pas été exécutée. Que s’est-il passé ?

• Vérifiez les exécutions suivantes qu’Azure Pipelines a planifiées pour votre pipeline. Vous pouvez trouver ces exécutions en sélectionnant l’action Exécutions planifiées dans votre pipeline. La liste est filtrée pour vous montrer uniquement les exécutions à venir au cours des prochains jours. Si cela ne répond pas à vos attentes, il est probable que vous avez mal tapé votre planification cron, ou que vous n’avez pas défini la planification dans la branche appropriée. Lisez la rubrique ci-dessus pour comprendre comment configurer des planifications. Réévaluez votre syntaxe cron. Toutes les heures pour les planifications cron sont au format UTC.

• Apportez une petite modification triviale à votre fichier YAML et envoyez cette mise à jour dans votre dépôt. S’il y a eu un problème lors de la lecture des planifications à partir du fichier YAML précédemment, il doit être résolu maintenant.

• Si vous avez des planifications définies dans l’interface utilisateur, vos planifications YAML ne sont pas respectées. Vérifiez que vous n’avez aucune planification d’interface utilisateur en accédant à l’éditeur de votre pipeline, puis en sélectionnant Déclencheurs.

• Il existe une limite au nombre d’exécutions que vous pouvez planifier pour un pipeline. En savoir plus sur les limites.

• Si aucune modification n’est apportée à votre code, il se peut qu’Azure Pipelines ne démarre pas de nouvelles exécutions. Découvrez comment remplacer ce comportement.

Mes plannings YAML fonctionnaient correctement. Mais ils ont cessé de travailler maintenant. Comment puis-je corriger cette erreur ?

• Si vous n’avez pas spécifié always:true, votre pipeline ne sera pas planifié, sauf si des mises à jour sont apportées à votre code. Vérifiez s’il y a eu des modifications de code et comment vous avez configuré les planifications.

• Le nombre de fois où vous pouvez planifier votre pipeline est limité. Vérifiez si vous avez dépassé ces limites.

• Vérifiez si quelqu’un a activé d’autres planifications dans l’interface utilisateur. Ouvrez l’éditeur de votre pipeline, puis sélectionnez Déclencheurs. Si quelqu’un a défini des planifications dans l’interface utilisateur, vos planifications YAML ne seront pas respectées.

• Vérifiez si votre pipeline est suspendu ou désactivé. Sélectionnez Paramètres pour votre pipeline.

• Vérifiez les exécutions suivantes qu’Azure Pipelines a planifiées pour votre pipeline. Vous pouvez trouver ces exécutions en sélectionnant l’action Exécutions planifiées dans votre pipeline. Si vous ne voyez pas les planifications attendues, apportez une petite modification triviale à votre fichier YAML et envoyez la mise à jour à votre dépôt. Cela devrait resynchroniser les planifications.

• Si vous utilisez GitHub pour stocker votre code, il est possible qu’Azure Pipelines ait été limité par GitHub lorsqu’il a tenté de démarrer une nouvelle exécution. Vérifiez si vous pouvez démarrer une nouvelle exécution manuellement.

Mon code n’a pas changé, mais une build planifiée est déclenchée. Pourquoi ?

• Vous avez peut-être activé une option pour toujours exécuter une build planifiée, même s’il n’y a aucune modification du code. Si vous utilisez un fichier YAML, vérifiez la syntaxe de la planification dans le fichier YAML. Si vous utilisez des pipelines classiques, vérifiez si vous avez activé cette option dans les déclencheurs planifiés.

• Vous avez peut-être mis à jour le pipeline de build ou une propriété du pipeline. Cela entraîne la planification d’une nouvelle exécution même si vous n’avez pas mis à jour votre code source. Vérifiez l’historique des modifications dans le pipeline à l’aide de l’éditeur classique.

• Vous avez peut-être mis à jour la connexion de service utilisée pour vous connecter au dépôt. Cela entraîne la planification d’une nouvelle exécution même si vous n’avez pas mis à jour votre code source.

• Azure Pipelines vérifie d’abord s’il existe des mises à jour de votre code. Si Azure Pipelines ne parvient pas à atteindre votre dépôt ou à obtenir ces informations, il crée une exécution informationnelle. Il s’agit d’une build factice pour vous informer qu’Azure Pipelines ne peut pas atteindre votre dépôt.

• Votre pipeline n’a peut-être pas une build complètement réussie. Pour déterminer s’il faut ou non planifier une nouvelle build, Azure DevOps recherche la dernière build planifiée complètement réussie. S’il n’en trouve pas, il déclenche une nouvelle build planifiée. Les builds planifiées partiellement réussies ne sont pas considérées comme réussies. Par conséquent, si votre pipeline n’a que des builds partiellement réussies, Azure DevOps déclenche des builds planifiées, même si votre code n’a pas changé.

Je vois l’exécution planifiée dans le panneau Exécutions planifiées. Toutefois, elle ne s’exécute pas à ce moment-là. Pourquoi ?

• Le panneau Exécutions planifiées affiche toutes les planifications potentielles. Toutefois, la planification peut ne pas s’exécuter, sauf si vous avez effectué des mises à jour réelles du code. Pour forcer l’exécution d’une planification, vérifiez que vous avez défini la propriété always dans le pipeline YAML ou que vous avez activé l’option pour toujours s’exécuter dans un pipeline classique.

Les planifications définies dans le pipeline YAML fonctionnent pour une branche, mais pas pour l’autre. Comment la corriger ?

Les planifications sont définies dans les fichiers YAML, et ces fichiers sont associés à des branches. Si vous souhaitez qu’un pipeline soit planifié pour une branche particulière, par exemple features/X, assurez-vous que le fichier YAML de cette branche contient la planification cron définie et qu’il contient les inclusions de branche appropriées pour la planification. Dans cet exemple, le fichier YAML de la branche features/X doit avoir le schedule suivant :

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

Pour plus d’informations, consultez Considérations relatives aux branches pour les déclencheurs planifiés.