LESSON 30分

トリガーとイベント

ストーリー

「ワークフローの構文は分かったか？次はトリガーを使いこなそう」

木村先輩が質問した。

「CIをいつ走らせるのが最適だと思う？」

「えっと......pushするたびに？」

「それも正解だが、もっと細かく制御できる。 特定のブランチだけ、特定のファイルが変更された時だけ、 毎朝定時に、手動ボタンで...... トリガーを賢く設定すれば、無駄な実行を減らして コスト効率も上がるんだ」

イベントの種類

GitHub Actionsのトリガーイベントは大きく3つに分類できます。

イベントの分類

┌──────────────────────────────────────────┐
│  1. リポジトリイベント                       │
│     push, pull_request, release,          │
│     issues, create, delete ...            │
├──────────────────────────────────────────┤
│  2. スケジュールイベント                     │
│     schedule (cron)                        │
├──────────────────────────────────────────┤
│  3. 手動・外部イベント                       │
│     workflow_dispatch, repository_dispatch, │
│     workflow_call                           │
└──────────────────────────────────────────┘

pushイベント

コードがプッシュされた時に実行されます。

ブランチフィルタ

yaml
on:
  push:
    branches:
      - main                  # mainブランチのみ
      - 'release/**'          # release/ で始まるブランチ
      - '!release/**-beta'    # ただし -beta は除外

パスフィルタ

yaml
on:
  push:
    paths:
      - 'src/**'              # src/ 以下の変更のみ
      - 'package.json'        # package.json の変更
      - '!**/*.md'            # Markdownファイルは除外
      - '!docs/**'            # docs/ 以下は除外

タグフィルタ

yaml
on:
  push:
    tags:
      - 'v*'                  # v で始まるタグ (v1.0.0 等)
      - '!v*-rc*'             # ただし RC は除外

pull_requestイベント

PRが作成・更新された時に実行されます。

アクティビティタイプ

yaml
on:
  pull_request:
    types:
      - opened                # PR作成時
      - synchronize           # PRにpushした時
      - reopened              # PR再オープン時
    branches:
      - main                  # mainブランチへのPRのみ

PRイベントの全アクティビティタイプ

タイプタイミング
openedPRを新規作成した時
synchronizePRブランチに新しいコミットをpushした時
reopenedクローズされたPRを再度開いた時
closedPRをクローズした時
ready_for_reviewドラフトからレビュー可能になった時
labeledラベルが追加された時
review_requestedレビューリクエストされた時

PRとpushの使い分け

トリガー設計パターン

feature/* → push → CIなし（PRで実行するため不要）

pull_request → main
  → Lint + テスト + ビルド（PR のクオリティゲート）

push → main（マージ後）
  → ビルド + デプロイ（本番リリース）
yaml
# 推奨パターン: PRでCI、mainへのpushでCD
name: CI/CD Pipeline

on:
  pull_request:
    branches: [ main ]        # PR時はCIのみ
  push:
    branches: [ main ]        # マージ後はCDも実行

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

  cd:
    needs: ci
    if: github.event_name == 'push'    # pushイベント（マージ後）のみ
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production..."

scheduleイベント

cron構文でスケジュール実行します。

yaml
on:
  schedule:
    # ┌───── 分 (0 - 59)
    # │ ┌───── 時 (0 - 23) UTC
    # │ │ ┌───── 日 (1 - 31)
    # │ │ │ ┌───── 月 (1 - 12)
    # │ │ │ │ ┌───── 曜日 (0 - 6, 日曜=0)
    # │ │ │ │ │
    - cron: '0 0 * * 1-5'     # 平日 0:00 UTC (9:00 JST)
    - cron: '0 3 * * 0'       # 毎週日曜 3:00 UTC (12:00 JST)

スケジュール実行のユースケース

ユースケースcron式説明
毎朝のセキュリティスキャン0 0 * * *毎日0:00 UTC
週次の依存関係チェック0 3 * * 1毎週月曜 3:00 UTC
月次のパフォーマンステスト0 6 1 * *毎月1日 6:00 UTC
ナイトリービルド0 21 * * 1-5平日 21:00 UTC

workflow_dispatch（手動実行）

GitHub UIやAPIから手動でワークフローを実行します。

yaml
on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'デプロイ先環境'
        required: true
        type: choice
        options:
          - development
          - staging
          - production
      version:
        description: 'デプロイするバージョン'
        required: true
        type: string
        default: 'latest'
      skip_tests:
        description: 'テストをスキップする'
        required: false
        type: boolean
        default: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Show inputs
        run: |
          echo "Environment: ${{ inputs.environment }}"
          echo "Version: ${{ inputs.version }}"
          echo "Skip tests: ${{ inputs.skip_tests }}"

      - name: Run tests
        if: ${{ !inputs.skip_tests }}
        run: npm test

      - name: Deploy
        run: echo "Deploying ${{ inputs.version }} to ${{ inputs.environment }}"

workflow_call（再利用可能ワークフロー）

他のワークフローから呼び出せるワークフローを定義します。

yaml
# .github/workflows/reusable-deploy.yml
name: Reusable Deploy

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      aws_access_key:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to ${{ inputs.environment }}
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.aws_access_key }}
        run: echo "Deploying..."
yaml
# .github/workflows/main.yml（呼び出し側）
name: Main Pipeline

on:
  push:
    branches: [ main ]

jobs:
  deploy-staging:
    uses: ./.github/workflows/reusable-deploy.yml
    with:
      environment: staging
    secrets:
      aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}

  deploy-production:
    needs: deploy-staging
    uses: ./.github/workflows/reusable-deploy.yml
    with:
      environment: production
    secrets:
      aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}

イベント選定ガイド

目的推奨イベント理由
PRの品質チェックpull_requestマージ前にテストを実行
本番デプロイpush (main)マージ後に自動デプロイ
リリース作成push (tags)バージョンタグで起動
定期スキャンschedule毎日/毎週定時に実行
緊急デプロイworkflow_dispatch手動で即座に実行
共通処理workflow_call複数ワークフローで再利用

まとめ

ポイント内容
pushブランチ/パス/タグでフィルタ可能
pull_requestアクティビティタイプで細かく制御
schedulecron構文で定期実行
workflow_dispatch手動実行、入力パラメータ対応

チェックリスト

  • push/pull_request イベントのフィルタ設定ができる
  • pushとpull_requestの使い分けを理解した
  • schedule（cron）の構文を書ける
  • workflow_dispatch で手動実行ワークフローを作れる
  • workflow_call で再利用可能なワークフローを理解した

次のステップへ

次のセクションでは、GitHub Marketplace で公開されているアクションの活用方法を学びます。 車輪の再発明を避け、コミュニティの力を活用しましょう。

推定読了時間: 30分