Войти
RU

Сборка micro PHP на собственных раннерах (workflow standalone)

bin/jumphp export:standalone и app:export приклеивают игру или приложение к micro: статически собранному PHP (StaticPHP) с расширениями, нужными JumPHP. Micro собираются workflow .github/workflows/standalone.yml и публикуются как релиз standalone-<ключ> (ключ — отпечаток версии PHP, списка расширений, коммита StaticPHP и реестра и патчей JumPHP: tools/standalone-key.sh). Поэтому micro пересобирается, только если изменился один из этих элементов. На этой странице объясняется, как запустить этот workflow на ваших раннерах (ci-runner.md, чтобы их установить), и что машины GitHub давали бесплатно, а у ваших может не быть.

Запуск

Forge > репозиторий > Actions > standalone > Run workflow, либо из терминала (gh — это gh форджа в проекте JumPHP):

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: без micro для Linux (см. «Docker» ниже); тогда export:standalone собирает micro для Linux на компьютере пользователя
macos true / false false: без micro для Mac (только десктопные приложения); без раннера macOS задачи ждали бы бесконечно

Задача Windows занимает около 10 минут при закэшированных загрузках, 30–60 в самый первый раз. Её результат: https://<forge>/<владелец>/<репозиторий>/releases/download/standalone-<ключ>/micro-windows-x86_64.sfx.

Что было на машинах GitHub и чего может не быть на ваших

На GitHub тот же workflow «работал сам», потому что windows-latest и ubuntu-latest — образы, подготовленные GitHub. Собственный раннер — голая машина. Всё перечисленное ниже обрабатывается workflow или описано здесь:

Образ GitHub Ваш раннер Что делает workflow / что делаете вы
PowerShell 7 (pwsh), PHP, Composer, Git часто только Windows PowerShell 5.1 и Git шаги выполняются в Windows PowerShell; PHP 8.4 и Composer скачиваются (php.net, getcomposer.org, отпечаток проверяется), если их нет; usr\bin из Git добавляется в PATH
Windows на английском язык вашего Windows (французский...) VSLANG=1033 заставляет инструменты Visual Studio говорить по-английски: configure.js PHP читает вывод компоновщика и иначе останавливается с ошибкой 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
Docker в задаче Linux задача выполняется в контейнере без Docker см. ниже
Концы строк LF Git for Windows конвертирует в CRLF git config --global core.autocrlf false перед клонированием StaticPHP (патч его файлов опирается на их текст)

Docker: где нужен, а где нет

  • Задача Windows компилирует нативно с помощью Visual Studio. Она не использует Docker, а раннер Windows и не смог бы (контейнеры Linux под Windows работают через WSL2). Для этого ничего устанавливать не нужно.
  • Задача Linux запускает docker build docker/standalone, затем docker run StaticPHP. В контейнере задачи Docker нет, если только раннер его не предоставляет: смонтируйте в задачу сокет Docker хоста (или dind раннера) (container.options / valid_volumes в config.yml раннера) или используйте раннер Linux на WSL2 (ci-runner.md, раздел 4), настоящий Linux с Docker. Без этого запускайте с linux=false: bin/jumphp export:standalone <id> --linux собирает micro для Linux на компьютере, который экспортирует (около 15 минут, затем хранится в ~/.jumphp/standalone/).
  • Какой бы ни был раннер, никогда не копируйте и не переименовывайте micro под другим ключом: это будет PHP без нужных расширений, и исполняемые файлы ваших пользователей будут падать (Call to undefined function SDL_Init()). Если ключ изменился, micro нужно пересобрать.

Устранение неполадок

Журналы задач читаются на странице запуска в форже (задача > красный шаг); API форджа их не возвращает.

Симптом Причина / исправление
Задача key падает за 30 с, сразу после «Fetching the repository» контейнер задачи не разрешает имя форджа: у Docker-in-Docker раннера нет DNS наружу. Дайте ему: dns: [1.1.1.1, 9.9.9.9] для сервиса dind в compose-файле раннера. Проверка: docker run --network <новая сеть> node:20-bookworm getent hosts <forge>
Cannot find: pwsh in PATH workflow требует Windows PowerShell (shell: powershell); старая копия требовала pwsh. Обновите её
configure.js ... Erreur d'exécution Microsoft JScript после «Checking for link.exe» инструменты Visual Studio пишут на языке Windows. VSLANG=1033 (в workflow начиная с этой страницы)
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 ограничивает или отказывает для вашего адреса. Workflow повторяет попытки; первому запуску на новой машине может понадобиться вторая попытка. Загрузки сохраняются: каждая попытка продвигается дальше
GHESNotSupportedError: upload-artifact@v4 ... not currently supported вы используете Forgejo: возьмите workflow из этого репозитория (он публикует без артефактов)
Задачи macOS остаются в «waiting», и запуск никогда не завершается нет раннера macOS: -f macos=false
Cannot find path ...\buildroot\bin\micro.sfx сборка упала раньше: прочитайте строки выше (причина в них)

Для ИИ-агентов

Вас могут попросить «заставить workflow standalone работать на моём раннере». Прочитайте упавший шаг на странице запуска (попросите пользователя вставить его, если у вас нет доступа), меняйте workflow (он должен оставаться рабочим на GitHub: проверяйте github.server_url), а не машину пользователя, если только не отсутствует одно из требований выше (Git, Visual Studio Build Tools, Docker для задачи Linux): тогда скажите об этом пользователю и устанавливайте только с его согласия. Никогда не регистрируйте раннер, никогда не записывайте токен в файл, никогда не публикуйте micro, которое вы не собрали из текущих файлов командами этого workflow, никогда не переносите релиз под другой ключ. После успешного запуска проверьте файл (gh release view standalone-<ключ>, загрузка, отвечающая 200) и, для micro Windows, запустите с ним скрипт на машине раннера (copy /b micro.sfx + test.php test.exe, затем test.exe: версия PHP, extension_loaded('ffi')...).