自分のランナーで PHP の micro をビルドする（standalone ワークフロー）
bin/jumphp export:standalone と app:export は、ゲームやアプリケーションを micro に貼り付けます。micro とは、JumPHP が必要とする拡張を含めて
静的にビルドされた PHP（StaticPHP）です。micro は .github/workflows/standalone.yml ワークフローでビルドされ、
standalone-<キー> リリースとして公開されます（キーは、PHP のバージョン、拡張のリスト、StaticPHP のコミット、
そして JumPHP のレジストリとパッチのフィンガープリントです：tools/standalone-key.sh）。そのため micro は、これらのいずれかが
変わった場合にだけ再ビルドされます。このページでは、このワークフローを自分のランナーで実行する方法（インストールは ci-runner.md を参照）と、
GitHub のマシンが無料で提供していたもので、あなたのマシンにはないかもしれないものを説明します。
実行する
フォージ > リポジトリ > Actions > standalone > Run workflow、またはターミナルから（JumPHP プロジェクトでは gh はフォージのものです）：
gh workflow run standalone.yml -f extensions=tools/app-extensions.txt -f macos=false -f linux=false
| 入力 | 値 | |
|---|---|---|
extensions |
tools/standalone-extensions.txt（ゲーム：SDL、OpenGL、OpenAL）、tools/app-extensions.txt（デスクトップアプリ、IDE）、tools/hybrid-extensions.txt |
ビルドされる micro ＝ それぞれ独自のキー |
linux |
true / false |
false：Linux の micro を作らない（下の「Docker」を参照）。その場合 export:standalone はユーザーのコンピューター上で Linux の micro をビルドします |
macos |
true / false |
false：Mac の micro を作らない（デスクトップアプリのみ）。macOS のランナーがないと、ジョブは永遠に待ち続けます |
Windows のジョブは、ダウンロードがキャッシュされていれば約10分、最初の1回は30〜60分かかります。成果物：
https://<フォージ>/<オーナー>/<リポジトリ>/releases/download/standalone-<キー>/micro-windows-x86_64.sfx。
GitHub のマシンにあって、あなたのマシンにはないかもしれないもの
GitHub では同じワークフローが「ひとりでに動いて」いました。windows-latest と ubuntu-latest は GitHub が用意したイメージだからです。
自分のランナーは何も入っていないマシンです。以下はすべて、ワークフローが処理するか、ここで説明しています。
| GitHub のイメージ | 自分のランナー | ワークフローが行うこと / あなたが行うこと |
|---|---|---|
PowerShell 7（pwsh）、PHP、Composer、Git |
Windows PowerShell 5.1 と Git だけのことが多い | 手順は Windows PowerShell で実行されます。PHP 8.4 と Composer は、なければダウンロードされます（php.net、getcomposer.org、フィンガープリントを検証）。Git の usr\bin が PATH に追加されます |
| 英語版の Windows | お使いの Windows の言語（フランス語など） | VSLANG=1033 で Visual Studio のツールが英語で出力します。PHP の configure.js はリンカーの出力を読むため、そうしないと JScript エラーで停止します |
| Visual Studio 2022 | 自分でインストールが必要：Build Tools 2022、「C++ によるデスクトップ開発」ワークロード | Windows ランナーに必須の唯一のもの（Git for Windows と併せて）。install-windows-runner.ps1 が両方をインストールします |
api.github.com への高速アクセス、制限されることは稀 |
同じ API が 504 や「rate limit exceeded」を返す |
StaticPHP のダウンロードは4回再試行され、実行間で %USERPROFILE%\.spc-downloads に保持されます。Composer はソースからインストールします（--prefer-source） |
actions/upload-artifact@v4、download-artifact@v4 |
Forgejo は対応していません（「not currently supported on GHES」） | フォージでは、Windows のジョブが自分で micro をリリースに公開します（ジョブの github.token、フォージの API）。release ジョブは GitHub でのみ実行されます |
| Linux ジョブの Docker | ジョブは Docker のないコンテナ内で実行される | 下記を参照 |
| LF の改行 | Git for Windows が CRLF に変換する | StaticPHP をクローンする前に git config --global core.autocrlf false（そのファイルへのパッチはテキストに依存します） |
Docker：必要な場所と不要な場所
- Windows のジョブは Visual Studio でネイティブにコンパイルします。Docker は使わず、Windows のランナーには使えません（Windows 上の Linux コンテナは WSL2 経由です）。そのためにインストールするものはありません。
- Linux のジョブは
docker build docker/standaloneを実行し、続いて StaticPHP のdocker runを実行します。ジョブのコンテナには Docker がありません。 ランナーが提供する場合を除きます。ホストの Docker ソケット（またはランナーの dind）をジョブにマウントする（ランナーのconfig.ymlのcontainer.options/valid_volumes）か、WSL2 の Linux ランナー（ci-runner.md のセクション4）を使ってください。 Docker 付きの本物の Linux です。どちらもない場合はlinux=falseで実行します。bin/jumphp export:standalone <id> --linuxが、エクスポートを行う コンピューター上で Linux の micro をビルドします（約15分、その後~/.jumphp/standalone/に保持されます）。 - どのランナーでも、micro を別のキーでコピーしたり名前を変えたりしないでください。正しい拡張のない PHP になり、
ユーザーの実行ファイルがクラッシュします（
Call to undefined function SDL_Init()）。キーが変わったなら、micro は 再ビルドが必要です。
トラブルシューティング
ジョブのログは、フォージの実行ページで読めます（ジョブ > 赤い手順）。フォージの API はログを返しません。
| 症状 | 原因 / 対処 |
|---|---|
key ジョブが「Fetching the repository」の直後、30秒で失敗する |
ジョブのコンテナがフォージの名前を解決できません。ランナーの Docker-in-Docker に外部への DNS がないためです。DNS を与えてください：ランナーの compose ファイルの dind サービスに dns: [1.1.1.1, 9.9.9.9]。テスト：docker run --network <新しいネットワーク> node:20-bookworm getent hosts <フォージ> |
Cannot find: pwsh in PATH |
ワークフローは Windows PowerShell を要求します（shell: powershell）。古いコピーは pwsh を要求していました。更新してください |
「Checking for link.exe」の後に configure.js ... Erreur d'exécution Microsoft JScript |
Visual Studio のツールが Windows の言語で出力しています。VSLANG=1033（このページ以降、ワークフローに含まれています） |
ERROR: bison is required |
同じフォルダーでの途中までのビルドの後に発生します。StaticPHP は msys2 のツールを保持しますが、PATH には戻しません。作業スペースの spc/pkgroot、spc/source、spc/buildroot を削除して再実行してください（新しいジョブのようなきれいなスペースなら動作します） |
| StaticPHP のパッチが「not patched (StaticPHP changed)」または「Failed patch module」 | CRLF の改行（core.autocrlf false にして再クローン）、または以前の試行で既にパッチ済みのソースフォルダー（spc/source/php-src を削除） |
Failed to get GitHub release API info for madler/zlib / HTTP/2 504 |
api.github.com があなたのアドレスに対して制限または失敗しています。ワークフローは再試行します。新しいマシンでの初回実行は、2回目が必要な場合があります。ダウンロードは保持されるため、試行のたびに先へ進みます |
GHESNotSupportedError: upload-artifact@v4 ... not currently supported |
Forgejo を使っています：このリポジトリのワークフローを使ってください（アーティファクトなしで公開します） |
| macOS のジョブが「waiting」のままで、実行が終わらない | macOS のランナーがありません：-f macos=false |
Cannot find path ...\buildroot\bin\micro.sfx |
ビルドがその前に失敗しています。上の行を読んでください（原因はそこにあります） |
AI エージェントへ
「standalone ワークフローを自分のランナーで動くようにして」と頼まれることがあります。実行ページで失敗した手順を読み（アクセスできない場合は
ユーザーに貼り付けてもらってください）、ユーザーのマシンではなくワークフローを修正してください（GitHub でも有効なままである必要があります：
github.server_url をテストしてください）。ただし、足りないのが上記の前提条件（Git、Visual Studio Build Tools、
Linux ジョブ用の Docker）である場合は、ユーザーに伝え、ユーザーが承諾した場合にのみインストールしてください。ランナーを登録したり、
トークンをファイルに書いたり、このワークフローのコマンドで現在のファイルからビルドしていない micro を公開したり、リリースを別のキーに移したりしてはいけません。実行が成功したら、ファイルを確認し
（gh release view standalone-<キー>、200 を返すダウンロード）、Windows の micro の場合は、ランナーのマシン上でそれを使ってスクリプトを実行してください
（copy /b micro.sfx + test.php test.exe、続いて test.exe：PHP のバージョン、extension_loaded('ffi') など）。