GitHub Actionsを活用して、CMS更新時のAmplify再ビルド方法を模索した

CMSのデータを元にSSGを実行するアプリケーションをAmplify上で管理しています。

コンテンツの更新頻度があまり高くないのでSSGを採用していますが、いざ更新となった場合はCMS側の更新をフックに再ビルドをかける必要があります。

AmplifyはWebhook URLを発行できるのでそれを活用することも検討したのですが、CMS側で上手く対応できず、Github ActionsのWebhookを活用することにしました。

Github Actionsのworkflowでは、一部抜粋ですがAWS CLIを利用し、AmplifyのStart Jobを実行しています。

- name: Start Amplify Job
  run: |
    aws amplify start-job \
      --app-id ${{ vars.AMPLIFY_APP_ID }} \
      --branch-name ${{ vars.BRANCH_NAME }} \
      --job-type RELEASE

最初のうちはある程度うまくいっていたのですが、複数コンテンツを短期間で更新された際に問題が発生しました。

Start Jobの実行数制限

Start Jobの実行数が2回までという制限に悩まされました。

An error occurred (LimitExceededException) when calling the StartJob operation (reached max retries: 2)

複数のコンテンツが短期間に更新された際に溢れたjobの分は軒並みエラーになってしまいました。

コンテンツ更新のタイミングによっては、実行されているビルドに更新内容が取り込まれる可能性がありますが、そうでない場合は問題になります。

リトライを導入した

失敗した際にリトライするのはどうかと思い探してみたところ、 nick-fields/retry というアクションを発見しました。
https://github.com/nick-fields/retry

失敗かタイムアウトした際に再実行してくれるactionです。

これを元に以下のように書き換えました。

- name: Start Amplify Job with Retry
  uses: nick-fields/retry@v3
  with:
  timeout_minutes: 1
  max_attempts: 2
  command: |
  aws amplify start-job \
    --app-id ${{ vars.AMPLIFY_APP_ID }} \
    --branch-name ${{ vars.BRANCH_NAME }} \
    --job-type RELEASE

start-job自体は一瞬で終わるので最低限にしています。

Concurrency設定も追加

ただ、このままだと短期間に複数実行された際に、GitHub Actions側でリトライするjobが溜まることになり、結局Amplifyへのjob startリクエストが多い状態になりかねないので、GithubのConcurrency設定も追加しました。

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

これにより短期間に複数実行された際も、後半のjobのみ実行できるようになります。

実際どうなのか

今のところは想定通りに上手く実行できています。

とはいえ、Githubの失敗通知が度々くるのとリトライ分はGithub Actionsの時間を消費するので他の対応も検討したいところです。