Utiliser des déclencheurs pour contrôler le moment d’exécution de votre workflow

Effectué

Vous disposez maintenant d’un workflow de travail qui déploie votre fichier Bicep dans votre environnement Azure. Toutefois, chaque fois que vous modifiez votre fichier, vous devez exécuter manuellement votre workflow. Dans cette unité, vous allez apprendre à déclencher automatiquement votre workflow chaque fois que votre code Bicep change.

Notes

Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.

Qu’est-ce qu’un déclencheur de workflow ?

Un déclencheur de workflow est une condition qui, lorsqu’elle est remplie, exécute automatiquement votre workflow en fonction des règles que vous créez. Vous pouvez configurer des déclencheurs pour exécuter votre workflow à intervalles planifiés. Vous pouvez également définir des déclencheurs pour exécuter votre workflow chaque fois qu’un fichier de votre référentiel est modifié. Vous pourriez choisir la deuxième option, car il est en effet judicieux d’exécuter tous vos tests et étapes de déploiement chaque fois qu’une personne modifie votre code.

Si vous n’utilisez pas de déclencheur automatique, une personne peut apporter une modification à un fichier Bicep, et même la valider et l’envoyer (push) au référentiel, mais si elle oublie d’exécuter le workflow, il y aura une différence entre les définitions de ressources dans votre fichier Bicep et les ressources déployées dans votre environnement Azure. Supposons que quelques commits et envois (push) supplémentaires soient effectués, mais pas déployés. Si quelqu’un introduit une erreur ou une configuration inexistante dans le fichier Bicep dans l’une de ces modifications, il peut être difficile de détecter l’erreur parmi les multiples validations qui sont ensuite déployées simultanément. Après un certain temps, vous n’aurez plus confiance dans le fait que votre code Bicep représente véritablement votre infrastructure et il perd alors une partie de sa valeur.

Lorsque vous configurez votre workflow pour qu’il s’exécute chaque fois que vous mettez à jour vos fichiers, dès que vos modifications sont envoyées, votre workflow commence à s’exécuter. Vous recevez des commentaires instantanés sur la validité de vos modifications et vous pouvez être sûr que votre environnement de production est toujours à jour.

Déclencheurs d’événements d’envoi

Un type déclencheur commun est un déclencheur d’événement d’envoi, aussi appelé déclencheur d’intégration continue ou déclencheur CI. Lorsque vous utilisez un déclencheur d’événements d’envoi, chaque fois que vous apportez une modification à une branche spécifique, le workflow s’exécute. Si vous commitez et que vous envoyez (push) une modification vers une branche différente, le workflow n’est pas déclenché et ne s’exécute pas. Il est courant d’utiliser ce type de déclencheur sur votre branche main ou votre branche par défaut, avec ce code :

on:
  push:
    branches:
      - main

Déclencher quand plusieurs branches changent

Vous pouvez configurer des déclencheurs pour exécuter votre workflow sur une branche spécifique ou sur des ensembles de branches. Par exemple, supposons que vous créez des branches de version qui contiennent le code que vous allez déployer pour une version spécifique de votre projet. Vous pouvez utiliser des noms de branche comme release/v1, release/v2, etc. Vous voulez exécuter votre workflow chaque fois que votre code change sur une branche qui commence par le nom release/. Vous pouvez utiliser un caractère générique ** :

on:
  push:
    branches:
      - main
      - 'release/**'

Vous pouvez exclure certaines branches aussi. Supposons que vous collaboriez avec des membres de votre équipe sur le projet. Vos collègues créent des branches de fonctionnalités pour tester leurs idées dans les fichiers Bicep. Toutes ces branches de fonctionnalités reçoivent des noms comme feature/add-database, feature/improve-performance, etc. Vous souhaitez exécuter automatiquement votre workflow sur toutes les branches, à l’exception des branches de fonctionnalités créées par vos collègues. Avec la propriété exclude, vous vous assurez que le workflow n’est pas automatiquement déclenché pour les modifications apportées aux branches de fonctionnalités :

on:
  push:
    branches-ignore:
      - 'feature/**'

Notes

Vous pouvez exclure certaines branches à l’aide du caractère !. Supposons que vous souhaitiez déclencher votre workflow pour votre branche principale et toutes les branches de version, à l’exception des versions alpha. Vous pouvez utiliser le caractère ! pour exprimer cela :

on:
  push:
    branches:
      - main
      - 'release/**'
      - '!release/**-alpha'

Vous ne pouvez pas utiliser branches et branches-ignore ensemble dans un seul déclencheur, le caractère ! vous permet donc de contrôler avec flexibilité le comportement de votre déclencheur.

Filtres de chemin

Parfois, certains fichiers de votre référentiel ne sont pas liés à votre déploiement. Par exemple, dans votre référentiel, vous pouvez avoir un dossier deploy qui contient votre code Bicep et un sous-dossier docs qui contient vos fichiers de documentation. Vous souhaitez déclencher votre workflow quand une personne apporte une modification à un des fichiers Bicep dans le dossier déployer, mais vous ne souhaitez pas déclencher le workflow si une personne modifie uniquement un fichier de documentation. Pour configurer un déclencheur en vue de répondre aux modifications apportées à un dossier spécifique dans votre référentiel, vous pouvez utiliser un filtre de chemin d’accès :

on:
  push:
    paths:
      - 'deploy/**'
      - '!deploy/docs/**'

Si quelqu’un valide une modification qui ne met à jour qu’un fichier de documentation, le workflow ne s’exécute pas. Mais si quelqu’un modifie un fichier Bicep, ou même s’il modifie un fichier Bicep en plus d’un fichier de documentation, le déclencheur exécute le workflow.

Notes

Vous pouvez également utiliser paths-ignore, qui fonctionne de la même façon que le mot clé branches-ignore. Toutefois, vous ne pouvez pas utiliser paths et paths-ignore dans le même déclencheur.

Planifier pour que votre workflow s’exécute automatiquement

Vous pouvez exécuter votre workflow selon une planification définie, et non en réponse à une modification de fichier. Par exemple, vous pouvez exécuter une version de votre code Bicep toutes les nuits ou déployer automatiquement un environnement de test tous les matins. Utilisez le mot clé schedule et définissez la fréquence à l’aide d’une expression cron :

on:
  schedule:
    - cron: '0 0 * * *'

Notes

Une expression cron est une séquence de caractères mise en forme qui spécifie la fréquence à laquelle un événement doit se produire. Dans cet exemple, 0 0 * * * signifie une exécution tous les jours à minuit UTC.

Dans un fichier YAML, vous devez ajouter des guillemets autour des chaînes qui contiennent le caractère *, comme les expressions cron.

L’événement de planification exécute toujours votre workflow sur la branche par défaut de votre référentiel.

Utiliser des déclencheurs multiples

Vous pouvez combiner des déclencheurs et des planifications, comme dans cet exemple :

on:
  push:
    branches:
      - main
  schedule:
    - cron: '0 0 * * *'

Lorsque vous créez un déclencheur de branche et un déclencheur planifié dans le même workflow, le workflow s’exécute chaque fois qu’un fichier est modifié sur la branche définie dans le déclencheur et selon le calendrier que vous avez défini. Dans cet exemple, le workflow s’exécute tous les jours à minuit UTC, mais aussi chaque fois qu’une modification est envoyée à la branche primaire.

Conseil

Une bonne pratique consiste à définir des déclencheurs pour chaque workflow. Si vous ne définissez pas de déclencheurs, par défaut, votre workflow s’exécute automatiquement dès qu’un fichier est modifié sur une branche quelconque, ce qui n’est souvent pas ce que vous souhaitez.

Déclencheurs Webhook

GitHub fournit également des événements webhook qui s’exécutent automatiquement lorsque certains événements se produisent dans votre référentiel. Ces événements incluent la création d’une branche, la mise à jour de vos problèmes GitHub ou les modifications apportées aux demandes de tirage. En règle générale, ces événements ne nécessitent pas l’exécution de votre workflow de déploiement Bicep, mais vous pouvez exécuter d’autres automatisations à la place.

Contrôle d’accès concurrentiel

Par défaut, GitHub Actions permet à plusieurs instances de votre workflow de s’exécuter simultanément. Cela peut se produire lorsque vous effectuez plusieurs validations dans une branche dans un laps de temps réduit, ou si une exécution précédente n’est pas terminée lorsque le programme se déclenche à nouveau.

Dans certains cas, le fait d’avoir plusieurs exécutions simultanées de votre workflow ne pose aucun problème. Lorsque vous travaillez avec des workflows de déploiement, il peut être toutefois difficile de s’assurer que vos exécutions de workflow n’écrasent pas vos ressources ou votre configuration Azure de manière inattendue.

Pour éviter ces problèmes, vous pouvez appliquer le contrôle d’accès concurrentiel. Utilisez le mot clé concurrency, puis spécifiez une chaîne cohérente dans toutes les exécutions de votre workflow. Il s’agit généralement d’une chaîne codée en dur, comme dans cet exemple :

concurrency: MyWorkflow

GitHub Actions vérifie ensuite que le code attend la fin de l’exécution de workflow active avant de démarrer une nouvelle exécution.