ci: dev デプロイを直列化して CloudFormation の競合を防ぐ（#112） - #113
Merged
Conversation
全 PR が同じ dev ステージへデプロイするため、複数 PR がほぼ同時に更新される とスタックが UPDATE_IN_PROGRESS のままになり、先着以外が deploy 段階だけで 失敗していた。差分の内容とは無関係に落ちるため都度の手動再実行が必要だった。 serverless-dev に concurrency group を設定してリポジトリ全体で 1 本ずつに 直列化する。ref を含めない固定 group にすることで PR 間の競合を無くし、 実行中のデプロイを中途半端に打ち切らないよう cancel-in-progress は false に する。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoGxJDiZa8c2E3PVAnxbK8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
close #112
課題
serverless-dev.ymlはon: pull_requestで全 PR に対して走り、いずれも同じdevステージ（CloudFormation スタックgithub-notifications-slack-dev）へデプロイする。複数 PR がほぼ同時に更新されると、先着以外が下記で落ちる。差分の内容とは無関係で、ビルドは成功したうえで deploy 段階だけが失敗する。再実行で復旧するが、複数 PR を並行して進めると必ず踏む。
変更内容
serverless-devに concurrency group を設定し、リポジトリ全体で 1 本ずつに直列化する。groupに ref を含めない のが要点。PR ごとに分けると「別 PR と同時に走る」という競合の原因そのものが残る。cancel-in-progress: false。実行中のデプロイを打ち切るとスタックが中途半端な状態で残りうるため、待たせる方を選んだ。案の比較
issue に挙げた3案のうち案1を採った。
案2（PR ごとにステージを分ける）は採らなかった。
serverless.ymlの関数はschedule: rate(1 minute)で動くため、ステージを増やすとその数だけ bot が並走して同じ GitHub アカウントの通知をポーリングし、Slack へ重複投稿したうえで互いに既読化し合う。競合は消えても実害が大きい。PR クローズ時のsls removeの後始末が要る点も含めて割に合わない。案3（PR での dev デプロイをやめる） は deploy が通るかを PR 時点で確認できなくなるため単独では選ばなかった。
既知の制約
同一 group の待機中 run は最新1本しか保持されず、3本目が来ると待機中だったものは GitHub 側でキャンセルされる。その PR は deploy 未検証のままになるので、確認したい場合は再実行が要る。失敗ではなくキャンセル表示になるので区別はつく。
この挙動はワークフロー側のコメントにも残している。
動作確認
concurrencyが意図した値でパースされることを確認（group: serverless-dev/cancel-in-progress: False）補足
serverless-prod.ymlもpush: [master]で同じ構造をしており、master への連続マージで同種の競合が起きうる。この PR のスコープ外なので別途 issue を立てた（本文コメント参照）。Generated by Claude Code