Verwenden von Triggern zum Steuern von Workflowausführungen

• 5 Minuten

Sie verfügen jetzt über einen funktionierenden Workflow, der Ihre Bicep-Datei in Ihrer Azure-Umgebung bereitstellt. Bei jeder Änderung Ihrer Dateien müssen Sie jedoch Ihren Workflow manuell ausführen. In dieser Lerneinheit erfahren Sie, wie Sie die Ausführung Ihres Workflows automatisch immer auslösen, wenn sich Ihr Bicep-Code ändert.

Was ist ein Workflowtrigger?

Bei einem Workflowtrigger handelt es sich um eine Bedingung, die bei Erfüllung Ihren Workflow automatisch basierend auf von Ihnen erstellten Regeln ausführt. Sie können Trigger so festlegen, dass Ihr Workflow in geplanten Intervallen ausgeführt wird. Sie können auch Trigger festlegen, damit Ihr Workflow jedes Mal ausgeführt wird, wenn eine Datei in Ihrem Repository geändert wird. Die zweite Option bietet sich an, da es sinnvoll ist, alle Ihre Tests und Bereitstellungsschritte jedes Mal auszuführen, wenn jemand Ihren Code ändert.

Wenn Sie keinen automatischen Auslöser verwenden, kann jemand eine Änderung an einer Bicep-Datei vornehmen und sie sogar committen und zum Repository pushen. Doch wenn die Person vergisst, den Workflow auszuführen, gibt es einen Unterschied zwischen den Ressourcendefinitionen in Ihrer Bicep-Datei und den Ressourcen, die in Ihrer Azure-Umgebung bereitgestellt werden. Stellen Sie sich vor, was passiert, wenn mehrere Commits und Pushes ausgeführt werden, aber keine Bereitstellung erfolgt. Wenn bei einer dieser Änderungen ein Fehler oder eine Fehlkonfiguration in die Bicep-Datei eingefügt wird, kann es schwierig sein, den Fehler in den vielen Commits zu finden, die später gleichzeitig bereitgestellt werden. Nach einer Weile haben Sie dann kein Vertrauen mehr darin, dass Ihr Bicep-Code wirklich Ihre Infrastruktur darstellt, wodurch deren Wert unterminiert wird.

Wenn Sie Ihren Workflow so einrichten, dass er jedes Mal ausgeführt wird, wenn Ihre Dateien aktualisiert werden, wird die Ausführung Ihres Workflows in dem Moment gestartet, in dem die Änderungen gepusht werden. Sie erhalten sofort Feedback zur Gültigkeit Ihrer Änderung und können sicher sein, dass Ihre Produktionsumgebung immer auf dem neuesten Stand ist.

Pushereignistrigger

Ein gängiger Triggertyp ist ein Pushereignistrigger, der auch als Continuous Integration-Trigger oder CI-Trigger bezeichnet wird. Wenn Sie einen Pushereignistrigger verwenden, wird der Workflow jedes Mal ausgeführt, wenn Sie eine Änderung an einem bestimmten Branch vornehmen. Wenn Sie eine Änderung committen und in einen anderen Branch pushen, wird der Workflow nicht ausgelöst und ausgeführt. Es ist üblich, diesen Triggertyp mit folgendem Code für den Standard- oder Mainbranch zu verwenden:

on:
  push:
    branches:
      - main

Auslösen, wenn sich mehrere Branches ändern

Sie können Trigger einrichten, um Ihren Workflow in einem oder mehreren festgelegten Branches auszuführen. Angenommen, Sie erstellen Releasebranches, die den Code enthalten, den Sie für ein bestimmtes Release Ihres Projekts bereitstellen möchten. Sie verwenden dazu Branchnamen wie release/v1, release/v2 usw. Sie möchten Ihren Workflow jedes Mal ausführen, wenn sich Code in einem Branch ändert, dessen Name mit release/ beginnt. Sie können den Platzhalter ** verwenden:

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

Sie können auch bestimmte Branches ausschließen. Angenommen, Sie arbeiten gemeinsam mit Teammitgliedern an Ihrem Projekt. Ihre Kollegen erstellen Featurebranches, um ihre Ideen in Bicep-Dateien auszuprobieren. Alle Featurebranches haben Namen wie feature/add-database, feature/improve-performance usw. Sie möchten Ihren Workflow automatisch in allen Branches ausführen, außer in den Featurebranches, die Ihre Kollegen erstellen. Mithilfe der exclude-Eigenschaft stellen Sie sicher, dass der Workflow nicht automatisch für Änderungen an Featurebranches ausgelöst wird:

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

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

Pfadfilter

Manchmal befinden sich Dateien in Ihrem Repository, die nicht in Zusammenhang mit Ihrer Bereitstellung stehen. Beispielsweise könnten Sie in Ihrem Repository über einen Ordner deploy, der Ihren Bicep-Code enthält, sowie einen Unterordner docs verfügen, der Ihre Dokumentationsdateien enthält. Sie möchten Ihren Workflow auslösen, wenn jemand eine Änderung an einer der Bicep-Dateien im Ordner deploy vornimmt, aber Sie möchten den Workflow nicht auslösen, wenn nur eine Dokumentationsdatei geändert wird. Zum Einrichten eines Triggers, der auf Änderungen in einem bestimmten Ordner in Ihrem Repository reagiert, können Sie einen Pfadfilter verwenden:

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

Wenn jemand eine Änderung committet, die nur eine Dokumentationsdatei aktualisiert, wird der Workflow nicht ausgeführt. Wenn jedoch eine Bicep-Datei oder eine Bicep-Datei zusätzlich zu einer Dokumentationsdatei geändert wird, führt der Trigger den Workflow aus.

Planen der automatischen Ausführung Ihres Workflows

Sie können Ihren Workflow nach einem festgelegten Zeitplan ausführen anstatt als Reaktion auf eine Dateiänderung. Beispielsweise können Sie ein nachts veröffentlichtes Release Ihres Bicep-Codes ausführen oder jeden Morgen automatisch eine Testumgebung bereitstellen. Verwenden Sie das Schlüsselwort schedule, und legen Sie die Häufigkeit mithilfe eines cron-Ausdrucks fest:

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

Das Zeitplanereignis führt Ihren Workflow immer im Standardbranch Ihres Repositorys aus.

Verwenden mehrerer Trigger

Sie können Trigger und Zeitpläne wie in diesem Beispiel kombinieren:

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

Wenn Sie einen Branchtrigger und einen Zeitplantrigger im selben Workflow angeben, wird der Workflow jedes Mal ausgeführt, wenn eine Datei in dem Branch geändert wird, der im Trigger festgelegt wurde, und gemäß dem von Ihnen angegebenen Zeitplan. In diesem Beispiel wird der Workflow täglich um Mitternacht (UTC) ausgeführt und außerdem immer, wenn eine Änderung in den Mainbranch gepusht wird.

Webhooktrigger

GitHub stellt auch Webhookereignisse zur Verfügung, die automatisch ausgeführt werden, wenn bestimmte Ereignisse in Ihrem Repository eintreten. Zu diesen Ereignissen gehören das Erstellen eines Branches, Updates bei GitHub-Problemen oder Änderungen an Pull Requests. Im Allgemeinen ist es für diese Ereignisse nicht erforderlich, Ihren Bicep-Bereitstellungsworkflow auszuführen, aber Sie können stattdessen andere Automatisierungen ausführen.

Gleichzeitigkeitssteuerung

GitHub Actions ermöglicht standardmäßig die gleichzeitige Ausführung mehrerer Instanzen Ihres Workflows. Diese Situation kann eintreten, wenn Sie innerhalb kurzer Zeit mehrere Commits für einen Branch ausführen, oder falls eine vorherige Ausführung nicht abgeschlossen wurde, wenn Ihr Zeitplan das nächste Mal ausgelöst wird.

In einigen Situationen ist es kein Problem, wenn mehrere Instanzen Ihres Workflows ausgeführt werden. Wenn Sie jedoch mit Bereitstellungsworkflows arbeiten, können Sie möglicherweise nicht problemlos sicherstellen, dass die Ausführungen Ihres Workflows Ihre Azure-Ressourcen oder -Konfiguration nicht auf eine unerwartete Weise überschreiben.

Um diese Probleme zu vermeiden, können Sie die Parallelitätssteuerung verwenden. Verwenden Sie das Schlüsselwort concurrency und geben Sie dann eine Zeichenfolge an, die für alle Ausführungen Ihres Workflows konsistent ist. Normalerweise handelt es sich um eine hartcodierte Zeichenfolge, wie in diesem Beispiel:

concurrency: MyWorkflow

GitHub Actions stellt nun sicher, dass zunächst die Ausführung aktiver Workflows abgeschlossen wird, bevor eine neue Ausführung gestartet wird.