Увійти
UK

Збирання 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')...).