GitHub と Cloudflare Workers Builds を連携すると、main や develop への push をきっかけに Worker を自動デプロイできる。

デプロイは自動化できても、成功したのか失敗したのかを Cloudflare の画面で確認し続けるのは手間がかかる。そこで、Workers Builds のイベントを Cloudflare Queues 経由で受け取り、Slack へ通知するようにした。

構成A

今回の環境は次のように分けている。

環境	Worker	ブランチ
staging	my-app-staging	develop
production	my-app	main

GitHub への push を受けた Cloudflare Workers Builds が、ビルドとデプロイを実行する。通知の経路は次のとおりである。

GitHub push
  ↓
Cloudflare Workers Builds
  ↓ build.succeeded / build.failed
Cloudflare Queue
  ↓
deploy-notifier Worker
  ↓
Slack

通知先が共通なら、notifier Worker は1つでよい。対象 Worker 名を見て staging と production を振り分ければ、通知の実装も設定も増えない。

notifier Worker

notifier Worker は Queue Consumer として動かす。受け取ったイベントから環境名、ブランチ、コミット SHA、コミットメッセージ、デプロイ先 URL を取り出し、Slack に送る。

Slack の Incoming Webhook URL は Worker のシークレットに登録した。

pnpm wrangler secret put SLACK_WEBHOOK_URL --name deploy-notifier

Webhook URL は wrangler.jsonc やリポジトリへ置かない。Issue、PR、ログにも出力しないようにする。

Event Subscription

Queue と Consumer を用意しただけでは、通知は届かなかった。Workers Builds から Queue へイベントを配送する Event Subscription がなかったためである。

Queue の Consumer が notifier Worker になっていても、Producer が 0 件ならメッセージは届かない。Workers Builds の build.succeeded と build.failed を Queue へ送る Subscription が必要だった。

pnpm wrangler queues subscription create my-build-events \
  --source workersBuilds.worker \
  --events build.succeeded,build.failed \
  --worker-name my-app-staging \
  --name my-build-events-staging

production 用も同じように作成する。

pnpm wrangler queues subscription create my-build-events \
  --source workersBuilds.worker \
  --events build.succeeded,build.failed \
  --worker-name my-app \
  --name my-build-events-production

Subscription で指定するイベント名は build.succeeded と build.failed だが、Queue に届くイベントの type は次の形式になる。

cf.workersBuilds.worker.build.succeeded
cf.workersBuilds.worker.build.failed

notifier Worker 側は、このイベント型を判定する必要がある。名前がずれていると、Queue まで届いていても Slack 通知は送られない。

Terraform にない設定

Cloudflare の構成は、可能な範囲で Terraform に寄せている。ただし、今回使った Event Subscription には Cloudflare 公式 Terraform Provider の専用リソースがなかった。

Queue 自体は Terraform で管理できる。一方で、Workers Builds の成功・失敗イベントを Queue へ送る Subscription は管理対象にできない。ここを local-exec で無理に Terraform から実行すると、Terraform state と実際の設定がずれやすい。

そのため、Event Subscription だけは Wrangler で管理することにした。コマンドを package.json に登録しておけば、設定が人の記憶だけに依存しない。

{
  "scripts": {
    "subscribe:build-events:staging": "wrangler queues subscription create ...",
    "subscribe:build-events:production": "wrangler queues subscription create ..."
  }
}

Terraform で管理できる設定まで Wrangler に寄せる必要はない。Provider が扱えない設定だけを Wrangler で管理する方が、責務を追いやすい。

動作確認

最初に staging の Subscription だけを作成し、Cloudflare の手動ビルドで Slack 通知を確認した。成功通知が届いた後、production 用の Subscription も作成した。

最終的に、staging と production のどちらでも手動ビルドの通知を確認できた。先に staging で確認しておくと、Webhook URL、Queue Consumer、イベント形式のどこに問題があるのかを production に影響させずに切り分けられる。

まとめ

Workers Builds の通知には、次の設定が必要になる。

1. Workers Builds と GitHub リポジトリの連携
2. Builds イベントを Queue へ配送する Event Subscription
3. Queue Consumer として動く notifier Worker

今回いちばん見落としやすかったのは Event Subscription だった。Queue と Consumer があるだけではイベントは流れない。まず staging で通知を確認してから production に広げると、安心して導入できる。