CodePipeline で trigger filter を活用する
Solution Architect の t_maru です。
CodePipeline の機能が強化され、以前記事で紹介していた以下のような複雑な構成をしなくても柔軟に CodePipeline を trigger できるようになりましたので、今回は CodePipeline の trigger filter についてご紹介します。
以前の記事
※ GitHub への status 反映については CodePipeline の trigger の設定とは関係のない事項ですので、本記事記載の方法で過去記事で紹介していた機能全てをカバーできているわけではありません
また、3/27 に実施した以下の Webiner の際に Pipeline V2 は Pull Request には未対応という内容で説明しましたが、この機能 update が実施される前の状態で検証した結果をお話させていただきました。本日時点では Pipeline の V2 を使用することで Pull Request trigger にも対応可能です。
CodePipeline の機能拡張
過去の記事でご紹介していたように、以前の仕様の CodePipeline は特定の branch を指定するか、tag に対するフィルターに対応 (Pipeline V2 のみ) した設定しかできませんでしたが、2024/2/9 に追加の機能拡張が行われました。
詳細なアナウンスは以下の公式サイトをご覧ください。
https://aws.amazon.com/jp/about-aws/whats-new/2024/02/codepipeline-trigger-filters-execution-modes/
このアップデートにより新しくできるようになった事項は下記です。
新しい Pipeline 実行モードの追加 (V2 のみ)
Queued モード
Parallel モード
追加の Pipeline trigger filter (GitHub, BitBucket, GitLab のみ)
Push, Pull Request に対して branch や file path の filter を設定できるようになった
Pipeline V2 を使う場合には、Queued、Parallel が選択できるようになりました。
以下に公式ドキュメントの引用を記載しますので、より詳細な情報が必要な方は引用元のドキュメントを参照ください。
QUEUED モード: 実行はキューに入れられた順序で 1 つずつ処理されます。これにはパイプラインタイプ V2 が必要です。
PARALLEL モード: PARALLEL モードでは、実行は相互に独立して同時に実行されます。実行は、他の実行が完了するのを待ってから開始または終了することはありません。これにはパイプラインタイプ V2 が必要です。
GitHub 等を Source code repository として使用している場合には、新しく branch や file path を trigger の条件で指定できるようになり、これらの条件には正規表現が使えるようになりましたので、例えば機能開発 branch には必ず `feat/` prefix をつけるという運用を取り入れる事により、これまでは対応できなかった Git-flow などの git branch モデルにも CodePipeline 単体で適応できるようになりました。
このため、以前の記事で紹介したような `CodeBuild → CodePipeline` というような回りくどいやり方をせずとも CI/CD Pipeline を構成することができるようになり、CI/CD 環境がよりシンプルに構成できるようになったことは非常に良い点だと思います。
filter 条件の記載ルールの詳細については下記を参照してください。
https://docs.aws.amazon.com/codepipeline/latest/userguide/syntax-glob.html
実際の使用感
簡単ではありますが、動作の検証を行ってみました。
いつものように CDK を使って構築しようとしましたが、この記事執筆時点ではまだ機能が組み込まれておりませんでした。
こちらの Pull Request が merge された後にリリースされる cdk には含まれてくるのではないかと思いますが、現時点では使用できませんので Management Console から設定を行いました。
https://github.com/aws/aws-cdk/pull/29127
https://github.com/aws/aws-cdk/pull/29128
※ Management console で作業すると自動的にリソースが作成されるものがありますが、リソースが不要になった際削除忘れが発生しがちなので検証目的のアカウント以外では手動によるリソース作成はあまりおすすめしません。
まず Source の設定ですが、GitHub の version 2 を選択して CodeStar Connection 経由で GitHub と連携します。
trigger filter を使用する場合でも、default のブランチ名の入力は必須のようです。
次に新しく追加になっている trigger の設定です。
今回は `feat/` という prefix が付く branch に対する Push を設定しました。
Pipeline の作成ウィザードでは上記に示したように 1 つの設定しか入力できませんが、Pipeline 作成後に追加の trigger 設定を行うことができますので、Push と Pull Request どちらにも対応させたい、といった場合には一度 Pipeline を作成してから追加作業を行います。
Pull Request に対する filter を追加してみました。
Pull Request に対する設定の場合は、Pull Request の Merge 先のブランチを `Branches` の `include` 項目で設定する必要があります。
今回は `main` ブランチに対する Pull Request 作成/更新 等を trigger 条件とするために上記のような設定としました。
また、作成した Pipeline に対して追加の Trigger source を指定することもできるようですので、必要に応じて Pipeline を編集してご利用いただければと思います。
以上までの設定で Git-flow の feature branch などで問題になる、不特定多数の branch に対する trigger (今回の例では `feat/` という prefix をつけた branch 名にするという運用ルールは必要ですが) を CodePipeline 単体で実現することができるようになりました。
ただし、GitHub との連携の場合、CodePipeline 単体では CI/CD の結果を GitHub 側に通知する機能が存在していないため、GitHub 側には status 表示されない点は注意が必要です。
CodePipeline 単体利用時の実行結果を GitHub に反映させる方法については別途検証を行い note 記事にてお知らせできればと思います。
まとめ
CodePipeline の機能アップデートにより、柔軟に Pipeline のワークフローをトリガーできるようになりました。
過去様々な検証を行って確立した方法が不要になるのは少しさみしくもありますが、Cloud を利用している場合にはよくあるケースですので、簡単に利用できるようになったことを喜びましょう！
今回ご紹介した例では
`feat/` という prefix がついた branch への Push
main branch へ向けて作成された Pull Request
という 2 つを trigger として設定しましたが、実際の開発で使う場合には Pull Request の trigger のみで事足りることが多い (基本的に機能を追加する際には Pull Request を使ってレビューをしてから merge することが多い) のではないかと思いますので、複数の trigger filter を設定する機会は少ないかもしれませんが、以前よりかなり柔軟な Pipeline の実行 trigger を実現できるようになりましたので、自分たちの開発スタイルにあった CI/CD Pipeline の構成をあらため考えてみるという時間を取ってみても良いかもしれません。