トリガーを使用してワークフローを実行するタイミングを制御する

完了

これで、Bicep ファイルを Azure 環境にデプロイするワークフローを使用できるようになりました。 ただし、ファイルを変更するたびに、ワークフローを手動で実行する必要があります。 このユニットでは、Bicep コードが変更されるたびにワークフローをトリガーして、自動的に実行する方法について説明します。

注意

このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。

ワークフロー トリガーとは

ワークフロー トリガーとは、それが満たされたときに、作成したルールに基づいてワークフローを自動的に実行する条件です。 スケジュール設定した間隔でワークフローを実行するようにトリガーを設定できます。 また、リポジトリ内のファイルが変更されるたびにワークフローを実行するようにトリガーを設定することもできます。 他のユーザーがコードを変更するたびにすべてのテストとデプロイの手順を実行することが推奨されるため、2 番目のオプションを選択することもできます。

自動トリガーを使用しない場合、他のユーザーが Bicep ファイルに変更を加え、それをコミットしてリポジトリにプッシュする可能性がありますが、そのユーザーがワークフローの実行を忘れた場合、Bicep ファイル内のリソース定義と、Azure 環境にデプロイされているリソースとの間に違いが生じます。 さらにいくつかのコミットとプッシュが行われますが、デプロイされなかったとします。 Bicep ファイルのこうした変更に誰かが組み込んだエラーや誤った構成がある場合、後で一括してデプロイされた複数のコミットの中からそのエラーを見つけ出すのは困難になる可能性があります。 しばらくすると、Bicep コードが本当にインフラストラクチャを表しているかどうかを確信できなくなり、その価値は損なわれます。

ファイルを更新するたびに実行されるようワークフローを設定すると、変更がプッシュされた瞬間に、ワークフローの実行が開始されます。 変更の有効性についてすぐにフィードバックを受け取り、運用環境が常に最新の状態であることを確認できます。

イベント トリガーをプッシュする

一般的なトリガーの種類は、"プッシュ イベント トリガー" です。これは "継続的インテグレーション トリガー" または "CI トリガー" とも呼ばれます。 プッシュ イベント トリガーを使用すると、特定のブランチに変更を加えるたびに、ワークフローが実行されます。 変更をコミットして別のブランチにプッシュした場合、ワークフローはトリガーされず、実行もされません。 次のコードを使用して、既定のブランチまたは "メイン" ブランチに対してこの種類のトリガーを使用するのが一般的です。

on:
  push:
    branches:
      - main

複数のブランチが変更されたときにトリガーする

特定のブランチ、またはブランチのセットに対してワークフローを実行するようにトリガーを設定できます。 たとえば、プロジェクトの特定のリリース用にデプロイするコードを含む "リリース ブランチ" を作成するとします。 release/v1 や release/v2 などのブランチ名を使用できます。 あなたは、名前が release/ で始まるブランチでコードが変更されるたびに、ワークフローを実行したいと考えています。 ** ワイルドカードを使用できます。

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

特定のブランチを除外することもできます。 たとえば、プロジェクトのチーム メンバーと共同作業をしているとします。 同僚は、Bicep ファイルでアイデアを試すための "機能ブランチ" を作成しました。 すべての機能ブランチには、feature/add-database や feature/improve-performance のような名前が付けられます。 あなたは、同僚が作成した機能ブランチを除くすべてのブランチで、ワークフローを自動的に実行したいと考えています。 exclude プロパティを使用すると、機能ブランチへの変更に対してワークフローが自動的にトリガーされないようにすることができます。

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

Note

特定のブランチを除外するには、! 文字を使用します。 たとえば、アルファ リリースを除き、メイン ブランチとすべてのリリース ブランチのワークフローをトリガーするとします。 これを表現するには、! 文字を使用します。

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

1 つのトリガーで branches と branches-ignore を同時に使用することはできないので、! 文字を使用してトリガーの動作を柔軟に制御することができます。

パス フィルター

場合によっては、デプロイに関係のないファイルがリポジトリに存在することがあります。 たとえば、リポジトリに、Bicep コードを含む deploy フォルダーと、ドキュメント ファイルを含む docs サブフォルダーがあるとします。 他のユーザーが deploy フォルダー内の Bicep ファイルに変更を加えたときはワークフローをトリガーしますが、他のユーザーがドキュメント ファイルのみを変更したときはワークフローをトリガーする必要がないとします。 リポジトリの特定のフォルダー内の変更に応答するようにトリガーを設定するには、"パス フィルター" を使用します。

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

ドキュメント ファイルのみを更新する変更を誰かがコミットした場合は、ワークフローは実行されません。 ただし、誰かが Bicep ファイルを変更した場合、またはドキュメント ファイルに加えて Bicep ファイルを変更した場合でも、トリガーによってワークフローが実行されます。

Note

また、branches-ignore キーワードと同様に機能する paths-ignore を使用することもできます。 ただし、paths と paths-ignore を同じトリガーで使用することはできません。

ワークフローが自動的に実行されるようにスケジュールする

ファイルの変更に応じてではなく、設定したスケジュールに基づいてワークフローを実行できます。 たとえば、Bicep コードの夜間リリースを実行したり、毎朝テスト環境を自動的にデプロイしたりすることができます。 schedule キーワードを使用し、cron 式を使用してその頻度を設定します。

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

Note

"cron 式" とは、何かを実行する頻度を示す特別な書式の文字のシーケンスです。 この例の 0 0 * * * は、"毎日午前 0 時 (UTC) に実行する" を意味します。

YAML ファイルでは、cron 式のように * 文字を含む文字列を引用符で囲む必要があります。

schedule イベントにより、常にリポジトリの既定ブランチ上でワークフローが実行されます。

複数のトリガーを使用する

次の例のように、トリガーとスケジュールを組み合わせることができます。

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

同じワークフロー内にブランチ トリガー "および" スケジュールされたトリガーを作成すると、トリガーに設定したブランチでファイルが変更されるたび、"および" 設定したスケジュールに基づいて、ワークフローが実行されます。 この例では、ワークフローは毎日午前 0 時 (UTC) に実行されるのに加えて、"メイン" ブランチに変更がプッシュされるたびに実行されます。

ヒント

ワークフローごとにトリガーを設定することをお勧めします。 トリガーを設定しない場合、既定では、いずれかのブランチでいずれかのファイルが変更されるたびにワークフローは自動的に実行されます。これは多くの場合、望ましい処理ではありません。

Webhook トリガー

GitHub には Webhook イベントも用意されています。これは、リポジトリで特定のイベントが発生したときに自動的に実行されます。 たとえば、誰かによるブランチの作成、GitHub のイシューの更新、プル要求の変更などのイベントです。 通常、このようなイベント時に Bicep デプロイ ワークフローを実行する必要はありませんが、代わりに他の自動化を実行する場合があります。

コンカレンシー制御

既定では、GitHub Actions により、ワークフローの複数のインスタンスを同時に実行できます。 これは、ブランチに複数のコミットを短時間で行った場合、または、スケジュールが次にトリガーされた時点で前の実行が完了していない場合に発生することがあります。

ワークフローの複数の同時実行は問題にならない場合もありますが、 ただし、デプロイ ワークフローを使用する場合、ワークフローの実行により、予期しない方法で Azure のリソースまたは構成が上書きされないようにするのが困難なことがあります。

このような問題を回避するには、" コンカレンシー制御" を適用します。 concurrency キーワードを使用し、ワークフローのすべての実行で一貫した文字列を指定します。 これは通常、次の例のようにハードコーディングされた文字列です。

concurrency: MyWorkflow

さらに、GitHub Actions を使用すると、アクティブなワークフローの実行が完了するのを待ってから、新しい実行を開始することが保証されます。