CI パイプライン分割
- 1ファイルから4ファイルに設定ファイルを分割した理由
- 実装時に出てきた問題点のメモ
GitHub Actions を4ファイルに分けた理由
当初は main.yml に CI をまとめていたが、責務・実行タイミング・権限が違う処理が1本に混ざり、変更のたびに全体が走る・読みにくい、という問題が出た。
そのため次の4つに分割した。
| ファイル | 狙い | 主な内容 |
|---|---|---|
backend.yml |
Go 変更時だけ品質チェック | golangci-lint、単体テスト（-race） |
frontend.yml |
フロント変更時だけ品質チェック |
npm ci、ESLint、tsc --noEmit、テスト（あれば） |
security.yml |
PR 時のみセキュリティゲート | gosec、Trivy（fs/image）、TruffleHog |
deploy.yml |
手動デプロイ用（将来の CD） | ECR へ Docker push（OIDC・workflow_dispatch） |
狙い（3点）
- paths フィルタ … バックエンドだけ触った PR でフロント CI が走らない（逆も同様）
- 失敗の切り分け … 「品質」「セキュリティ」「デプロイ」で Actions の見え方を分ける
-
権限の最小化 … セキュリティは
security-events: write、デプロイは OIDC 用id-token: writeを必要なジョブだけに付与
共通設定として concurrency（同一ブランチの古い実行をキャンセル）と、各ファイル先頭のコメントで「いつ動くか・何をするか」を記載している。
なぜ分けたか
モノレポ（Go + Next.js）の CI を1ファイルにまとめると、変更のたびに全部が走り、セキュリティスキャンとデプロイの権限も混ざる。そこで 品質（BE/FE）・セキュリティ（PRのみ）・CD（手動） に分け、paths で差分実行し、失敗原因と権限をファイル単位で切り分けた。
実装中に出た修正
CI / ツール周り
| 項目 | 内容 |
|---|---|
| ツールのバージョン固定 | Action タグだけでなく、実行バイナリも明示（例: golangci-lint v2.12.2、trivy-action @v0.36.0、gosec @v2.26.1、trufflehog @v3.95.3）。再現性と「昨日は通った」の防止 |
| Node.js on Actions |
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true（GitHub の JS アクション向け Node 24 移行期限対応）。フロントのビルド自体は setup-node で 22 を指定 |
| TruffleHog |
base: ${{ github.event.pull_request.base.sha }} / head: HEAD。BASE=HEAD だと差分比較できず失敗するため修正。fetch-depth: 0 で履歴取得 |
| Trivy | 存在しないタグ参照で落ちたため、リリースタグに合わせて aquasecurity/trivy-action@v0.36.0 に固定 |
| ワークフロー分割 |
main.yml 廃止 → 4 ファイル化 |
アプリコード（CI を通すための修正）
| 項目 | 内容 |
|---|---|
| Firebase → ADC |
WithCredentialsJSON 廃止に合わせ firebase.NewApp(ctx, nil)。認証は GOOGLE_APPLICATION_CREDENTIALS（ローカルは JSON パス、本番は ECS 等で設定） |
| Go | golangci-lint の errcheck / staticcheck 指摘対応、脆弱性のある依存の更新 |
| フロント | ESLint の any 排除、next/image 利用に伴う remotePatterns 設定 |