CodePipelineは、GitHubなどのソースへのpushと連携し、push時に自動実行するのが一般的ですが、誤った実行を防ぐため承認ステージを設けるケースがあります。
上記の構成で、GitHubへの連続push が行われた場合、どのような動作になるのかサポートに問い合わせたため、頂いた回答を元に以下に整理します。
前提として、CodePipelineには実行モードがあり、実行モード(SUPERSEDED モード、QUEUED モード)によって動作が異なるため、それぞれの実行モードごとに動作を記載します。
SUPERSEDED モード(デフォルト) の動作
SUPERSEDEDモードでは、承認ステージの前で待機できる実行は1つのみとなります。したがって、承認ステージで承認が行われずに実行が滞っている場合、待機できる実行は最新の実行のみとなります。
したがってプッシュA,B,C,Dと立て続けに4回Githubへプッシュし、承認ステージで承認を行わない場合、以下のような実行状況となります。
- 承認ステージの前で待機する実行 プッシュD
- 承認ステージ プッシュAの承認待ち
※プッシュB,Cは後続から来たプッシュDに置き換えられる動作。
承認ステージで放置し続けるとどうなる？
承認ステージにはタイムアウト期間があります。デフォルトでは7日間ですが、最小5分、最大60日まで変更が可能です。
タイムアウト期間を超えて承認が行われずに放置された場合、パイプラインの当該実行(承認待ち)が失敗となります。この場合、承認ステージでタイムアウトした実行のみが失敗となり、承認ステージの前で待機していた実行が承認ステージに進みます。
したがってSUPERSEDEDモードにおいて、プッシュA,B,C,Dと立て続けに4回Githubへプッシュし、承認ステージで承認されずタイムアウトした場合、以下のような実行状況となります。
- 承認ステージの前で待機する実行 プッシュD
- 承認ステージ プッシュAの承認待ち
↓ 承認ステージがタイムアウト - 承認ステージの前で待機する実行 なし
- 承認ステージ プッシュDの承認待ち
QUEUED モードでの動作
QUEUEDモードでは、SUPERSEDEDモードのように待機する実行を上書きすることはありません。実行された順番通りにキューに入れられた状態で待機します。
したがってプッシュA,B,C,Dと立て続けに4回Githubへプッシュし、承認ステージで承認を行わない場合、以下のような実行状況となります。
- 承認ステージの前でキューに入れられた実行 プッシュB,C,D
- 承認ステージ プッシュAの承認待ち
参考資料
[1] パイプライン実行の仕組み
https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/concepts-how-it-works.html
[2] AWS CodePipeline のクォータ https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/limits.html
