CD ワークフローを cmd/* 由来の matrix による並列デプロイへ刷新

[kantacky]

概要

単一サービス前提だった CD ワークフローを刷新し、cmd/* から生成した matrix で各デプロイ対象を並列にデプロイする方式へ変更します。サービス/ジョブの増減に対し、ワークフローを編集せず cmd/ への追加だけで自動追従できるようにすることが目的です。

変更点

CD ワークフロー（cd.yml / set-env アクション）

• set-env アクションに cmd/* を走査する set-matrix ステップを追加し、デプロイ matrix を JSON で出力。末尾 -api を Cloud Run Service、それ以外を Cloud Run Job として分類する。
• 全 cmd ターゲットを 1 つのイメージに同梱する方針に合わせ、image_tag をサービス名非依存に変更。build-and-push は 1 回だけ実行する。
• 単一サービス向けの service_name 出力を廃止し、サービス/ジョブ名へ付与する service_suffix 出力（prod は空）に置き換え。
• deploy ジョブを matrix 化し、*-api は deploy-cloudrun、それ以外は gcloud run jobs deploy でデプロイ（Job は作成/更新のみで実行はしない）。いずれも共有イメージの起動コマンドを /bin/<name> に切り替える。
• 不要になった env（REGION / AR_REPOSITORY / IMAGE_NAME）を削除。
• ポリシーに従い、各 GitHub Actions をタグから SHA 固定へ変更（Renovate 用にタグをコメント併記）。

CI ワークフロー（ci.yml）

• concurrency group 名を整理し、暫定的に固定していた mise のバージョンピンを解除。

ビルド（Dockerfile）

• ビルド対象に announcement-api と user-api を追加。

確認内容

• set-matrix が cmd/* から想定どおりの Service/Job 分類で matrix を生成すること。
• 共有イメージ 1 つで各ターゲットが /bin/<name> 起動に切り替わること。

[devin-ai-integration]

レビュー

cmd/* からの動的 matrix 生成によるデプロイ自動化は設計として良いです。サービス追加時にワークフロー編集が不要になる点が大きなメリットです。以下、気になる点を挙げます。

---

1. prd vs prod の不一致（Bug — PR #19 から引き継ぎ）

workflow_dispatch の選択肢は prd ですが、set-env アクションの suffix 判定は "$TARGET_ENVIRONMENT" = "prod" をチェックしています。PR #19 と同じ問題なので、どちらかで統一が必要です。

2. cmd/* の全エントリが matrix に含まれる問題

現在の cmd/ ディレクトリ:

academic-api, announcement-api, apply-table-privileges, atlas-loader,
build-class-change-notifications-job, dispatch-notifications-job, migrate, user-api

• atlas-loader: Dockerfile のビルド対象に含まれていないため、イメージ内に /bin/atlas-loader が存在しません。デプロイは失敗します。
• apply-table-privileges: Dockerfile でビルドされていますが、対応する Cloud Run Job が存在するか不明です。

対策案:

• .deployignore 的な除外リストを持つ
• cmd/ 内に deploy 対象を示す marker ファイル（例: .deploy）を配置する
• set-matrix スクリプト内で除外リストをハードコードする

3. migrate vs migrate-job の命名不一致

PR #19 では Cloud Run Job 名が migrate-job ですが、cmd/ ディレクトリ名は migrate です。PR #21 の matrix 方式では migrate がそのまま Cloud Run Job 名になります。既存の Cloud Run リソース名が migrate-job の場合、デプロイが失敗するか新しいジョブが作成されます。Cloud Run 側のリソース名と cmd/ ディレクトリ名の対応を確認してください。

4. Docker ビルドのキャッシュ削除

PR #19 では docker/build-push-action + GHA キャッシュ（cache-from: type=gha, cache-to: type=gha,mode=max）を使っていましたが、PR #21 では docker build --no-cache に変更されています。ビルド時間が大幅に増加する可能性があります。

docker/build-push-action を引き続き使うか、少なくとも --no-cache を外すことを検討してください。

5. fetch-depth: 0 + submodules: true

build-and-push ジョブの checkout で fetch-depth: 0（全履歴）と submodules: true が指定されていますが、Docker ビルドに全履歴やサブモジュールは不要なはずです。デフォルト（shallow clone）の方が高速です。

6. IS_PUSH_TO_MAIN の github.base_ref チェック

IS_PUSH_TO_MAIN="${{ github.event_name == 'push' && (github.ref == 'refs/heads/main' || github.base_ref == 'main') }}"

push イベントでは github.base_ref は空なので、github.base_ref == 'main' は常に false です。冗長な条件なので削除して問題ありません。

7. env_vars の一律適用

deploy-cloudrun と gcloud run jobs deploy の両方で同じ env_vars（DB_IAM_USER, DB_NAME, INSTANCE_CONNECTION_NAME）を渡しています。全ターゲットが同じ DB 設定を必要とするなら問題ありませんが、今後ジョブごとに異なる設定が必要になった場合の拡張性を考慮しておくとよいかもしれません。

8. 良い点

• Actions の SHA 固定 + タグコメント併記 👍
• set-env アクションへのロジック分離は再利用性が高い
• matrix の fail-fast: false は並列デプロイに適切
• secrets → vars への移行は正しい判断