Skip to content

Home

Jump to bottom
fumikito edited this page Apr 4, 2026 · 17 revisions

Taroskyのオーガニゼーションで共有しているワークフロー＆複合アクションです。

ワークフロー

.github/workflowsに格納されています。それ自体で完結します。各オプションはymlファイルの先頭に記載されているinputs項目で確認できます。オプションはjob内のwithで指定します。

PHPUnit

PHP+MySQL+WordPressをインストールし、ユニットテストを行います。リポジトリにcomposerが入っており、PHPUnitをcomposer scriptから実行できる必要があります。 デフォルトのコマンドは test です。変更する場合は composer_command: unittest というように指定してください。

jobs:
  test:
    strategy:
      matrix:
        php: [ '7.3', '7.4', '8.0' ] # PHP versions to check.
        wp: [ 'latest', '5.9' ]      # WordPress version to check.
    uses: tarosky/workflows/.github/workflows/wp-unit-test.yml@main
    with:
        php_version: ${{ matrix.php }}
        wp_version: ${{ matrix.wp }}

コードカバレッジ

coverage: true を指定すると、pcovを使ったコードカバレッジ計測が有効になります。結果はGitHub Job Summaryに出力され、coverage.xml（Clover形式）がartifactとしてアップロードされます。

jobs:
  test:
    strategy:
      matrix:
        php: [ '7.4', '8.0' ]
        wp: [ 'latest', '5.9' ]
    uses: tarosky/workflows/.github/workflows/wp-unit-test.yml@main
    with:
        php_version: ${{ matrix.php }}
        wp_version: ${{ matrix.wp }}
        # PHP 8.0 + latest の組み合わせでのみカバレッジを計測
        coverage: ${{ matrix.php == '8.0' && matrix.wp == 'latest' }}

呼び出し側の phpunit.xml.dist に <coverage> セクションが必要です。また、composer test が PHPUnit を直接呼んでおり、-- でPHPUnit引数を渡せる前提です。

<coverage processUncoveredFiles="true">
  <include>
    <directory suffix=".php">./src</directory>
  </include>
</coverage>

WordPressのテスト環境を動作させるためには、WordPressテストスイートを用意しなければならず、WP-CLIチームがメンテナンスしているinstall-wp-tests.shなどを使うことが求められます。

このアクションでは指定したWordPressとPHPのバージョンをインストールし、MySQLを起動してテストのための環境を用意します。

wp-envのようなDockerを使って開発している場合はGitHub ActionsでDockerを動かすことでローカルと同じテスト環境を再現できます。

PHP CodeSniffer

PHPでcomposerをインストールし、スクリプトを実行します。composer lint で動作します。コマンド名を変更する場合は composer_command: lint_php で指定してください。

jobs:
  phpcs:
    uses: tarosky/workflows/.github/workflows/phpcs.yml@main
    with:
      version: 8.0

PHP Short Open Tag

PHP8.0から <? が非推奨となりましが、この記法はPHP_CodeSnifferでは見つけることができないケースがあり、この結果、本番環境でFatal Errorを起こすことがありました。 このワークフローではPHPファイルをスキャンし、ショートオープンタグを見つけるとエラーになります。

pathでスキャンするパスを指定してください。デフォルトはリポジトリルートです。

jobs:
  php-shor-open-tag:
    uses: tarosky/workflows/.github/workflows/php-short-open-tag.yml@main
    with:
      path: 'wp-content/themes/my-theme' # WordPressを丸ごとディレクトリに入れている場合など

PHP Lint

Wordpress公式ディレクトリでは、SVNのpre-commitフックでphp -l file.php を全PHPファイルに対して実行し、エラーが起きるとリジェクトします。composerなどを利用している場合、vendorディレクトリの中にある依存ライブラリがひっかかるケースもあり、なおかつデプロイという最終段階になってはじめて露見するので、事前にこのチェックを通過しておくとわかりやすいです。 pathでスキャンするパスを指定してください。デフォルトはリポジトリルートです。

W.I.P ビルドスクリプトの指定などは実装予定です。

jobs:
  phplint:
    uses: tarosky/workflows/.github/workflows/phplint.yml@main
    with:
      version: 8.1 # デプロイする際のPHPバージョンがわかっている場合など
      path: 'wp-content/themes/my-theme' # WordPressを丸ごとディレクトリに入れている場合など

npmテスト

Nodeをインストールし、npmでテストを行います。npm スクリプトで lint が動作することが前提です。また、packageにコマンド名を渡すことで、ビルドが成功するかを検証することも可能です。これはdependabotなどを有効にしている場合に活用できます。

node_version を省略すると、リポジトリルートの .node-version ファイルから自動的にバージョンを読み取ります。.node-version で統一管理している場合は省略を推奨します。

jobs:
  assets:
    uses: tarosky/workflows/.github/workflows/npm.yml@main
    with:
      # node_version を省略すると .node-version を自動参照
      command: test # デフォルトは lint
      package: build # この場合、 npm run build を実行。指定なしなら何もしない

明示的にバージョンを指定することもできます。

jobs:
  assets:
    uses: tarosky/workflows/.github/workflows/npm.yml@main
    with:
      node_version: "22"
      command: lint

backlog

Backlogの課題番号がコミットメッセージに含まれている場合、通知を行います。

  • tarosky-bot というユーザーがBacklogの当該プロジェクトのメンバーになっている必要があります。
  • BACKLOG_API_KEY という名称でAPIキーがプロジェクトまたは組織で利用できる必要があります。
  • secrets: inherit を指定し、BacklogのAPIキーをワークフローが利用できるようにしてください。
  • host を変更すると、Backlog スペースを変更できます。
jobs:
  notify:
    uses: tarosky/workflows/.github/workflows/backlog.yml@main
    with:
      project: PJ_STANDARD
    secrets: inherit

タグをブランチに限定する

タグでプロダクションをリリースするような場合、そのタグがメインブランチに所属しているかどうかを確認します。 リリース用のジョブの前に実行してください。

jobs:
  # タグ付きコミットなら、それがmainブランチにあるのかチェックする
  tags-check:
    uses: tarosky/workflows/.github/workflows/check-tag-in-branch.yml@main
    if: contains(github.ref, 'refs/tags/')
    with:
      allowed_branch: "main"
  # リリース作業のジョブ
  release:
    needs: tag-check # mainブランチのタグだけで実行
    environment:
      name: production
      url: https://example.com
    steps:
      # 以下、リリース作業のステップ

自動PR

設定したトリガーから指定するブランチへのPRを自動で作成します。デフォルト値では main ブランチへのPRが指定されており、staging ブランチから main ブランチへの自動PR作成を想定しています。PRのマージ先ブランチ名、PRタイトル、PRボディテキスト、付与するラベルを指定できます。

name: Auto PR to main branch from staging
on:
  push:
    branches: [staging]
jobs:
  auto-pr:
    uses: tarosky/workflows/.github/workflows/auto-pr.yml@main

Claude PR レビュー

CIが通ったPRをClaudeが自動レビューします。WordPressプラグイン開発の観点（フック・セキュリティ・パフォーマンス・設計）でコードレビューし、リスク・スコープのラベルを付与します。

前提条件: リポジトリのシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/claude-review.yml
name: Claude Code PR Review

on:
  workflow_run:
    workflows: ["Test Plugin"] # CIワークフロー名に合わせて変更
    types: [completed]

jobs:
  setup:
    if: |
      github.event_name == 'workflow_run' &&
      github.event.workflow_run.conclusion == 'success' &&
      github.event.workflow_run.event == 'pull_request' &&
      github.event.workflow_run.head_repository.full_name == github.repository
    runs-on: ubuntu-latest
    outputs:
      pr_number: ${{ steps.pr.outputs.number }}
    steps:
      - name: Get PR number from branch
        id: pr
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          PR_NUMBER=$(gh pr list \
            --repo "${{ github.repository }}" \
            --head "${{ github.event.workflow_run.head_branch }}" \
            --json number --jq '.[0].number')
          echo "number=$PR_NUMBER" >> "$GITHUB_OUTPUT"

  auto-review:
    needs: setup
    if: needs.setup.outputs.pr_number != ''
    uses: tarosky/workflows/.github/workflows/claude-review.yml@main
    with:
      plugin_name: my-plugin-name  # ← プラグイン名に変更
      ci_checks: "PHPStan Level 5, PHPCS, PHPUnit"  # ← 実際のCIチェック内容に変更
      pr_number: ${{ fromJSON(needs.setup.outputs.pr_number) }}
      head_sha: ${{ github.event.workflow_run.head_sha }}
    secrets: inherit

プラグイン固有の観点を追加したい場合は custom_focus を指定します。

    with:
      plugin_name: rich-taxonomy
      ci_checks: "PHPStan Level 5, PHPCS, PHPUnit, asset build"
      pr_number: ${{ fromJSON(needs.setup.outputs.pr_number) }}
      head_sha: ${{ github.event.workflow_run.head_sha }}
      custom_focus: |
        - Singleton パターンの遵守
        - リライトルール変更時の flush_rewrite_rules 確認

追いコミットがあった場合は、前回のレビューコメントを参照した差分レビューを自動的に行います。

Claude Issue トリアージ

未ラベル・内容が薄いIssueをClaudeが週次でトリアージします。ラベル付け・補足コメント・重複検出を自動で行います。

前提条件: リポジトリのシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/issue-triage.yml
name: Issue Triage

on:
  schedule:
    - cron: '0 1 * * 1'  # 毎週月曜 01:00 UTC
  workflow_dispatch:      # 手動実行も可能

jobs:
  triage:
    uses: tarosky/workflows/.github/workflows/issue-triage.yml@main
    with:
      plugin_name: my-plugin-name  # ← プラグイン名に変更
    secrets: inherit

対象期間を変更したい場合は days を指定します（デフォルト: 30日）。

    with:
      plugin_name: my-plugin-name
      days: 14  # 過去2週間のIssueのみ対象

動作内容:

アクション 条件
bug / enhancement / question / wontfix ラベル付与 全対象Issue
duplicate ラベル + 参照コメント 既存Issueと重複していると判断された場合
補足コメント（再現手順等を依頼） 本文が薄い・再現手順がないバグ報告など
ai-triaged ラベル付与 処理完了したIssue（次回以降スキップされる）

WP Plugin Audit

WordPress.org APIとサポートフォーラムのデータを基に、プラグインの健全性をClaudeが監査します。競合プラグインとの比較、サポートトレンドの分析、メンテナンス状態のチェックを行い、アクション可能なIssueを自動作成します。

前提条件: リポジトリのシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/plugin-audit.yml
name: Plugin Health Audit

on:
  schedule:
    - cron: '0 3 1 * *'  # 毎月1日 03:00 UTC
  workflow_dispatch:
    inputs:
      dry-run:
        description: 'trueならIssue作成しない'
        type: boolean
        default: false

jobs:
  audit:
    uses: tarosky/workflows/.github/workflows/plugin-audit.yml@main
    with:
      slug: my-plugin-slug  # ← WordPress.org のプラグインslugに変更
      language: 'ja'
      max_issues: 3
      dry_run: ${{ github.event.inputs.dry-run == 'true' }}
    secrets:
      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Issue作成数を変更したい場合は max_issues を指定します（デフォルト: 5）。

    with:
      slug: my-plugin-slug
      max_issues: 10        # 最大10件のIssueを作成
      dry_run: true          # まずドライランで確認

分析観点:

観点 内容 ラベル
サポートフォーラム 未解決率・繰り返しパターンの検出 support-trend
競合比較 タグベースで類似プラグインを検索し機能ギャップを分析 feature-gap
健全性 最終更新日・WP互換性・PHP要件・解決率 health-alert

自動作成されるラベル: wp-plugin-audit, support-trend, feature-gap, health-alert

重複防止: 既存の wp-plugin-audit ラベル付きIssueとタイトルを比較し、類似Issueはスキップされます。

Claude Assistant

Issue やPR のコメントで @claude とメンションすると、Claudeが文脈を読み取って応答します。コードの質問、リファクタ依頼、Issue の相談など、自由な対話に利用できます。

前提条件: リポジトリ（またはOrganization）のシークレットに ANTHROPIC_API_KEY が設定されていること。

# .github/workflows/claude-assistant.yml
name: Claude Assistant

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  assistant:
    uses: tarosky/workflows/.github/workflows/claude-assistant.yml@main
    secrets: inherit

モデルやトリガーフレーズを変更したい場合は with で指定します。

    with:
      model: claude-opus-4-6       # デフォルト: claude-sonnet-4-6
      trigger_phrase: '@claude-bot'  # デフォルト: @claude

アクセス制御: リポジトリに対して write 権限を持つユーザー（OWNER / MEMBER / COLLABORATOR）のみがトリガーできます。外部ユーザーのコメントはスキップされます。

他のClaudeワークフローとの違い:

ワークフロー 用途
Claude PR レビュー CI通過後に自動でコードレビュー
Claude Issue トリアージ 週次スケジュールで自動でラベル付け
Claude Assistant @claude メンションで対話的に応答

Playground Preview

PRごとにWordPress Playgroundのプレビューリンクを自動生成します。PRにプッシュするとプラグインがビルドされ、Playgroundで即座に動作確認できるURLがPRコメントに投稿されます。

2つの共有ワークフローで構成されています。

ワークフロー トリガー 役割
playground-preview-build.yml pull_request プラグインZIPをビルドしてアーティファクトとしてアップロード
playground-preview-publish.yml workflow_run アーティファクトを公開URLに配置し、PRにプレビューコメントを投稿

前提条件:

  • リポジトリに .distignore ファイルがあること（ZIPから除外するファイルの一覧）
  • ビルドコマンドが正常に動作すること（デフォルト: composer install --no-dev --prefer-dist && npm ci && npm run package）

呼び出し側のリポジトリには以下の2ファイルを用意します。

ビルドワークフロー（PR時に実行）:

# .github/workflows/playground-build.yml
name: Playground Build

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  build:
    uses: tarosky/workflows/.github/workflows/playground-preview-build.yml@main

パブリッシュワークフロー（ビルド完了後に実行）:

# .github/workflows/playground-publish.yml
name: Playground Publish

on:
  workflow_run:
    workflows: ["Playground Build"]  # ↑のワークフロー名に合わせる
    types: [completed]

jobs:
  publish:
    if: >
      github.event.workflow_run.conclusion == 'success' &&
      github.event.workflow_run.event == 'pull_request'
    uses: tarosky/workflows/.github/workflows/playground-preview-publish.yml@main
    secrets: inherit

カスタマイズ例:

ビルド設定を変更したい場合は with で指定します。

  build:
    uses: tarosky/workflows/.github/workflows/playground-preview-build.yml@main
    with:
      plugin_slug: my-plugin       # デフォルト: リポジトリ名
      php_version: '8.0'           # デフォルト: 7.4
      node_version: '20'           # デフォルト: .node-version を自動参照
      build_command: 'npm ci && npm run build'  # ビルドコマンドを変更
      retention_days: 3            # アーティファクト保持日数（デフォルト: 7）

パブリッシュ側で古いアーティファクトの保持数を変更できます。

  publish:
    uses: tarosky/workflows/.github/workflows/playground-preview-publish.yml@main
    with:
      plugin_slug: my-plugin       # ビルド側と合わせる
      artifacts_to_keep: '5'       # PR毎に保持する古いアーティファクト数（デフォルト: 2）
    secrets: inherit

仕組み:

  1. PRにプッシュすると playground-preview-build.yml がプラグインをビルドし、ZIPをアーティファクトとしてアップロード
  2. ビルド成功後 playground-preview-publish.yml が workflow_run で起動
  3. アーティファクトを公開URLに配置し、WordPress Playgroundのブループリントを生成
  4. PRにPlaygroundプレビューリンク付きのコメントが自動投稿される

複合アクション

複合アクションは job.steps で指定します。workflowと同様、オプション項目をwithで指定します。

distignore

.distignore ファイルがリポジトリにある場合、記載されているファイルをすべて削除します。リリース前の処理などに便利です。

jobs:
  release:
    steps:
      - name: Clean Package
        uses: tarosky/workflows/actions/distignore@main

wp-readme

README.md をWordPressに対応した readme.txt に変換します。wp-readmeを利用しています。

jobs:
  release:
    steps:
      - name: Generate readme.txt
        uses: tarosky/workflows/actions/wp-readme@main

versioning

GitHubのタグ情報を元に、style.cssなどのタグを書き換えます。prefix を指定すると、　version から削除する文字列を指定できます。

jobs:
  release:
    steps:
      - name: Versioning
        uses: tarosky/workflows/actions/versioning@main
        with:
          version: ${{ github.ref }} # 大体の場合はGitHubのタグを参照します。
          files: style.css # カンマ区切りで記載できます。

Clone this wiki locally