setup-phpでGitHub ActionsのPHP環境を組み立てる

PHP環境をActionの入力でそろえる

shivammathur/setup-phpは、GitHub Actions上で指定したPHP版を有効化またはインストールし、必要な拡張機能、php.iniの値、コードカバレッジ用ドライバー、Composerなどのツールを設定するActionです。アプリのテスト前にOSごとのシェル手順を分散させず、ワークフローの入力として環境を記述することが目的です。

GitHubホスト型とセルフホスト型の両方に対応し、Ubuntu、Windows、macOSを対象にします。要求したPHP版があらかじめ入っていれば、その版へ切り替え、なければインストールするとREADMEは説明しています。メタデータでは言語はTypeScript、ライセンスはMIT、既定ブランチはmain、アーカイブ状態はfalseです。2026年6月8日時点の取得情報には、3,254スター、419フォーク、5件のオープンイシューが記録されています。これらは公開活動の手掛かりで、ワークフローの成功を保証する数値ではありません。

ランナーとPHP版の組み合わせ

READMEは、GitHubホスト型としてUbuntu 22.04、24.04、26.04のx86_64とaarch64、Windows Server 2022と2025、macOS Tahoe、Sequoia、Sonomaのarm64とx86_64を列挙しています。セルフホスト型はUbuntu、Debian、Windows、macOSを対象にします。PHPは多くのランナーで5.3から8.6まで、macOS ARM64の一部では5.6から8.6まで設定でき、8.6はナイトリービルドとして扱われます。

`lowest`、`highest`、`nightly`、`pre-installed`、メジャー版のワイルドカードなどの指定、ファイルや`composer.json`のplatform設定から版を読む経路もREADMEにあります。古いPHP版を選べることは互換性検証に便利ですが、PHP自体のサポート終了を解消する機能ではありません。ホストOS、CPUアーキテクチャ、事前インストール状態、依存する拡張機能を行列の軸にし、実際に使う組み合わせだけを段階的に増やします。

拡張機能とComposerツールの指定

`extensions`入力は、カンマ区切りの拡張機能名を受け取ります。Ubuntuではシステムパッケージ、PECL、Gitリポジトリから取得し、WindowsとmacOSではPECLバイナリまたはソースビルドを使うとREADMEは説明します。名前の前にコロンを付ければ無効化でき、`none`は共有拡張機能を無効にします。特定のPECL版やプレリリースは名前のサフィックスで指定できます。

`tools`入力は、Composer、PHPUnit、PHPStanなどの文書化されたツールと、`vendor/package`形式の任意のComposerパッケージを扱います。版を固定でき、pharのダウンロードではSHA-256またはSHA-512へ固定できます。拡張機能の導入元がOSパッケージかPECLかでビルド条件と脆弱性管理が変わるため、入力だけで同じバイナリが得られると考えず、PHP版、OS、アーキテクチャ、ツール版をログへ残します。

カバレッジとphp.iniを分けて調整する

`coverage`入力はXdebug、PCOV、noneから選びます。XdebugはサポートされるPHP版全体、PCOVはPHP 7.1以降が対象です。カバレッジレポートを作らないジョブ、phpdbgを使うジョブ、Blackfireでプロファイリングするジョブ、JITを動かすジョブでは、coverageをnoneにする案内があります。

`ini-file`はproduction、development、基本php.iniなしを選択し、`ini-values`はディレクティブをカンマ区切りで追加します。カンマを値に含める場合は引用符を使います。Composer向けには`COMPOSER_NO_INTERACTION`や`COMPOSER_NO_AUDIT`などの環境変数を設定し、GitHubトークン、Private Packagistトークン、`COMPOSER_AUTH_JSON`による認証も扱えます。カバレッジ、JIT、認証は一つの設定として雑に共有せず、テスト、プロファイル、デプロイなどジョブの目的ごとに分離します。

ナイトリー、デバッグ、キャッシュの使い分け

READMEは、ナイトリービルド、シンボル付きデバッグビルド、スレッドセーフなztsと非スレッドセーフ、`update`によるパッチ更新の強制、`verbose`による詳細ログを設定バリエーションとして挙げています。Ubuntuのマルチアーキテクチャ実行では`shivammathur/node`コンテナイメージを使い、セルフホストランナーと`act`に似たローカルテスト向けの案内もあります。PHP 8.0以降では、`ini-values`でopcacheディレクティブを設定してJITを構成できます。

拡張機能キャッシュは`shivammathur/cache-extensions`、Composer依存関係キャッシュは別のキャッシュ機構で、ワークフロー時間を短くする方法として説明されています。キャッシュキーにPHP版、OS、アーキテクチャ、拡張機能の版を含めないと、別環境の成果物を復元する危険があります。verboseログにはパスや取得先が含まれる可能性があるため、公開ログへ秘密を出さない条件を確認します。ナイトリーや強制更新は再現性と引き換えなので、通常のリリース検証から分離します。

GitHub Actionsのワークフローへ入れる境界

基本の利用は、Actionの入力へPHP版、拡張機能、ツール、ini、coverageを指定し、後続のComposer installやテストへ渡す形です。行列設定では複数のPHPとOSを組み合わせ、nightlyやdebug、thread safe、self-hostedの例もREADMEにあります。Actionが環境を作ることと、アプリの依存関係がその環境で動くことは別の確認です。特にPHP版を自動選択する`lowest`や`highest`は、依存解決の結果が変わるため、失敗ログとロックファイルを保存します。

Composer認証を使う場合は、GitHubやPrivate PackagistのトークンをActionの秘密として渡し、コマンドラインやキャッシュ、エラー出力に漏れないことを確認します。セルフホストランナーでは、前のジョブが残したPHP、拡張機能、Composerキャッシュ、環境変数が次のジョブへ影響しないよう、クリーンな実行単位を設計します。READMEが示すActionの入力を増やす前に、アプリの要件、ランナーの権限、外部ダウンロードの固定方法を記録します。

v2タグ、SHA固定、MITライセンス

READMEはv2タグを、マイナー版とパッチ版に追随するローリングタグとして推奨しています。セマンティックなリリース版やコミットSHAも使えますが、安定したワークフローではmainブランチを避けるよう注意します。入力、出力、環境フラグに破壊的変更がある場合だけ新しいメジャー版を付ける方針も説明されています。取得情報ではGitHub Releasesの最新として2.37.2、続いて2.37.1、2.37.0が記録されています。

ローリングタグは更新を受け取りやすい一方、いつ環境が変わったかを追いにくくなります。本番に近いCIではSHAまたは検証済みリリースへ固定し、更新の候補を別ジョブで確認する運用が合います。スクリプトと文書はMITライセンスですが、依存関係はそれぞれのライセンスに従います。PHPロゴの派生物はCC BY-SA 4.0とREADMEに記載されています。setup-phpが向くのは、入力をコードレビューできるCI環境を作りたいチームであり、Actionだけで互換性やセキュリティを自動保証したい用途ではありません。

編集部の結論

setup-phpは、GitHub Actionsで複数のPHP版と拡張機能、php.ini、カバレッジドライバー、Composerなどを同じActionの入力で準備したいチームに向きます。Ubuntu、Windows、macOSとホスト型・セルフホスト型をまたぐワークフローの差を減らせます。ただし、PHPの古い版、ナイトリービルド、PECL、認証トークン、キャッシュはそれぞれ失敗条件が違います。まず固定したPHP版とSHAで最小のジョブを組み、実際のランナー、拡張機能、秘密情報、キャッシュ復元を確認してから行列やローリングタグを広げてください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes