[アップデート] AWS CodePipeline のステージレベルの条件で AWS CodeBuild ルールが追加されました

[アップデート] AWS CodePipeline のステージレベルの条件で AWS CodeBuild ルールが追加されました

Clock Icon2025.03.17

いわさです。

AWS CodePipeline にはステージレベルの条件という機能がありまして、各ステージのアクションの実行前後で前処理や後処理を行うことができます。
先日この機能で使えるルールに「AWS CodeBuild」が追加されましたのでその内容を紹介したいと思います。
今回検証していく中で「AWS コマンド」もルール追加されていたことに気がついたので、今更ですがそちらも少し紹介します。

アップデート内容

アナウンスはこちらです。アナウンスの中では CodeBuild とコマンドのルールがステージレベルの条件内でルール指定できるようになったと言及されていますが、実際には今回追加されたのは CodeBuild ルールです。

https://aws.amazon.com/about-aws/whats-new/2025/03/aws-codepipeline-codebuild-commands-rule-stage-level-condition/

まずステージレベルの条件とは?という方もいるかもしれませんのでおさらいをしたいと思います。
ステージレベルの条件は次のアップデートで追加された AWS CodePipeline の新機能です。

https://dev.classmethod.jp/articles/aws-codepipeline-stage-level-conditions/

CodePipeline では任意の数のステージを定義し、その中で複数のアクションを実行することができます。
そのステージの開始条件を満たしているかチェックしたり、ステージが終了したタイミングで成功しているかチェックしたり、あるいはステージが失敗した時に後処理を行ったりすることができます。

このチェックや後始末の処理でルールを選択するのですが、いくつかのルールプロバイダが提供されています。
これまで CloudWatch Alarm、DeploymentWindow、LambdaInvoke、VariableCheck を使うことができていたのですが、2024 年 12 月のタイミングで「AWS コマンド」が追加され、今回のアップデートで「AWS CodeBuild」が追加されました。

18097BF0-6803-4C00-B84A-5345753EE35B.png

柔軟な処理という意味だと従来から LambdaInvoke を使うことも出来たのですが、実行時間など様々な制約を意識しつつ使う必要がありました。
今回の AWS CodeBuild であればより柔軟なカスタム前後処理を行うことが出来そうです。

使ってみる

ステージ前の入力条件、ステージの成功条件、ステージの失敗条件それぞれで設定することが出来ます。

676939A3-EF60-456A-8582-9850B400EFB7.png

また、各ルールでは AWS CodeBuild プロジェクトの指定に加えて、環境変数やロール ARN をオプションで設定可能です。

image.png

パイプラインを実行してみましょう。
Build ステージの開始前(Entry)に、別の CodeBuild プロジェクトが開始されました。
この CodeBuild プロジェクトの実行が成功した場合にこのステージが開始されます。

079CB68A-5401-4D79-A9BF-FFC8B059E920.png

続いてステージの終了後(Exit)です。
こちらは通常のステージ内アクションが終了した後に成功・失敗の判定を行っています。
以下はアクション自体は成功していますが、終了条件が失敗しており、これによってパイプライン全体としては失敗ステータスとなります。

85E7FFB6-6A6C-48A1-B484-F79BABAB4966.png

最後にこちらはステージの失敗条件ルールで、ステージアクションが失敗した場合に実行されます。環境のクリーンアップ用途で使うイメージだと思います。

EF33E2A5-6BF9-4861-820B-40FA4900BF64.png

さいごに

本日は AWS CodePipeline のステージレベルの条件で AWS CodeBuild ルールが追加されたので試してみました。

従来も LambdaInvoke ルールなどを活用して自由度の高い処理やチェックを行うことが出来ていましたが、今回 CodeBuild がサポートされたことでより制約に縛られない前後処理が行えるようになるのではないでしょうか。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.