1. 導入: なぜワークフロー再利用が重要なのか
多くのプロジェクトを抱える組織では、似たようなCI/CD構成が各リポジトリに散乱しがちです。例えば、全リポジトリで同じセキュリティスキャンやデプロイ手順を個別に管理すると、修正のたびに全リポジトリを更新しなければならず、極めて非効率です。Reusable Workflows（ワークフローの再利用）を活用すれば、共通処理を1つの「正解」リポジトリに集約し、各プロジェクトのパイプラインを簡潔に保つことができます。これは「DRY (Don’t Repeat Yourself)」の原則をCI/CDに適用する強力な手法です。
2. 基礎知識: 仕組みの理解
Reusable Workflowsは、あるワークフローから別のワークフローを呼び出す機能です。
呼び出し元（Caller）: 実際に実行されるワークフロー。
呼び出し先（Called）: 再利用される共通のワークフロー。
この仕組みにより、呼び出し先で定義されたジョブを、まるで自分のジョブの一部であるかのように呼び出すことができます。
3. 実装/解決策: 構成のポイント
まずは共通化したい処理を別リポジトリ（例: `my-org/shared-workflows`）の`.github/workflows/`に配置します。呼び出し先には、`on: workflow_call:` を記述する必要があります。これにより、このファイルが他から呼び出し可能であることをGitHubに伝えます。
4. サンプルプログラム
呼び出し先（共通リポジトリ: .github/workflows/security-scan.yml）
name: 共通セキュリティスキャン
on:
workflow_call: # 他のワークフローから呼び出される設定
inputs:
target-path:
required: true
type: string
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: セキュリティスキャン実行
run: echo “${{ inputs.target-path }} に対してスキャンを実行中…”
呼び出し元（各プロダクトリポジトリ: .github/workflows/ci.yml）
name: メインパイプライン
on: push
jobs:
call-security-scan:
# 共通リポジトリのワークフローを呼び出す
uses: my-org/shared-workflows/.github/workflows/security-scan.yml@main
with:
target-path: “./src” # 必要な引数を渡す
5. 応用・注意点: 現場での運用Tips
バージョン管理の徹底: 上記の例では`@main`を使用していますが、現場では安定性を高めるために`@v1.0.0`のようにタグやコミットハッシュで固定することを強く推奨します。そうしないと、共通ワークフローの変更が意図せず全プロジェクトに影響を与えてしまいます。
シークレットの継承: 呼び出し先でシークレットが必要な場合、`secrets: inherit`を指定することで、呼び出し元のシークレットをそのまま引き継ぐことが可能です。
複雑化の回避: 共通化しすぎると、逆に柔軟性が失われ、特定のプロジェクトで例外的な処理を追加するのが困難になることがあります。共通化する範囲は「全プロジェクトで共通であるべき最低限のルール」に留めるのが賢明です。
コメント