導入：なぜCIの実行条件を絞るべきなのか
日々の開発で「ドキュメントを少し修正しただけなのに、数十分かかる全テストが走り出してしまった」という経験はありませんか？CI/CDパイプラインにおいて、すべての変更で全工程を実行することは、リソースの無駄遣いだけでなく、キューの混雑を招き、結果として開発者のフィードバックを遅らせる原因になります。この記事では、GitHub Actionsを例に「特定のファイルやブランチの変更時のみCIを実行する」ための最適化テクニックを解説します。
基礎知識：トリガー最適化の仕組み
CIの実行条件を絞るために使われるのが「パス（paths）」や「ブランチ（branches）」のフィルタリング機能です。
paths: 指定したディレクトリやファイルの変更があった場合のみジョブを実行します。
paths-ignore: 指定したファイル（Markdownや画像など）が変更された場合は、CIをスキップします。
これらを適切に設定することで、プログラムコードに関係のない修正でビルドが走ることを防ぎ、CIの実行コストを大幅に削減できます。
実装：設定の具体的な手順
GitHub Actionsのワークフローファイル（.yml）で、トリガーイベントの配下にこれらのフィルタを設定します。例えば、srcディレクトリ配下のソースコードが変更された時のみビルドを実行し、README.mdなどのドキュメント変更時は無視する、といった制御が可能です。
サンプルプログラム：GitHub Actions設定例
以下の設定をワークフローファイル（例: .github/workflows/ci.yml）に記述することで、特定の条件でのみCIを動かすことができます。
name: CI Pipeline
pushイベントが発生した時にチェック
on:
push:
branches:
- main # mainブランチへのプッシュ時のみ実行
paths:
- ‘src/’ # srcディレクトリ以下の変更時のみ実行
paths-ignore:
- ‘docs/’ # docsディレクトリ配下の変更は無視する
- ‘.md’ # すべてのMarkdownファイルの変更は無視する
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: コードチェックアウト
uses: actions/checkout@v3
- name: ビルド実行
run: |
echo “ソースコードに変更があったためビルドを開始します”
# ここに実際のビルドコマンドを記述
npm run build
応用・注意点：現場で役立つ補足情報
1. 意図しないスキップに注意
pathsの設定を厳しくしすぎると、本来テストすべき重要な設定ファイル（例えば、CIの設定自体や依存関係リストなど）の修正を見逃す可能性があります。重要なファイルは必ずチェック対象に含めるよう意識してください。
2. 条件を分ける運用
ドキュメント修正時のみ実行したい「ドキュメントビルド専用のジョブ」を別に作成し、メインのテストジョブとは別にpathsを設定する構成も推奨されます。これにより、「コード用CI」と「ドキュメント用CI」を切り離し、より効率的なパイプラインを構築できます。
これらの設定を取り入れることで、CIの待ち時間を減らし、チーム全体の開発体験（DevEx）を向上させましょう。
コメント