GitHub Actions の応用で『CIの神器』を作る
GitHub Actions は基本機能を超えると Self-hosted Runner・Reusable Workflow・OIDC など多彩な強化が可能です。本記事では編集部の視点で、応用の要点を公開情報をもとに整理します。CI/CD 実践 もご参考に。
Self-hosted Runner の活用
(1) 大容量メモリ/GPU 必要時。(2) 専用キャッシュを保持できる。(3) 固定IP/プライベート接続。(4) セキュリティ強化：自社ネットワーク。(5) 運用コスト：管理人員必要。ARC (Actions Runner Controller) で k8s 上に動的展開する構成が現代的。
Reusable Workflow
(1) 複数リポジトリから呼び出し：workflow_call。(2) パラメータ化：inputs/outputs。(3) Secret の継承：secrets: inherit。(4) 標準化：チーム横断の規約。(5) versioning：tag/branch で版管理。
Composite Action
(1) 複数 step の集約。(2) action.yml で定義。(3) plug-and-play：他リポでも使える。(4) シンプル：JavaScript Action より敷居低い。(5) Docker Action と使い分け。
OIDC でセキュアな認証
(1) 短期トークン：長期キー不要。(2) AWS / GCP / Azure 連携。(3) id_token：claim ベースで認証。(4) Cloudflare / HashiCorp Vault連携。(5) セキュリティ大幅向上。Secrets 管理 もご参考に。
Matrix と並列実行
(1) matrix strategy：複数バージョン/OS。(2) include/exclude：細かい制御。(3) continue-on-error：1つ落ちても続行。(4) max-parallel：同時実行数制限。(5) shard 戦略：テスト並列化。Playwright 実践 もご参考に。
セキュリティのベストプラクティス
(1) GITHUB_TOKEN 権限最小化：read-only デフォルト。(2) third-party action のピン留め：commit SHA で。(3) Branch protection：必須レビュー。(4) Environment Protection：本番デプロイの承認制。(5) Secrets Scanning：Dependabot/CodeQL。
失敗しがちなパターン
(1) Self-hosted Runner の脆弱性：パッチ未適用。(2) キャッシュ汚染：依存ライブラリの差し替え。(3) 長期キー使用：OIDC 未活用。(4) workflow の複雑化：保守困難。(5) キャッシュサイズ上限：10GB(公開情報をもとに)。対策は、(1)定期パッチ、(2)signed cache、(3)OIDC 切替、(4)reusable workflow、(5)分割保存、です。