Zaloguj się
PL

Budowanie micro PHP na własnych runnerach (workflow standalone)

bin/jumphp export:standalone i app:export doklejają grę lub aplikację do micro: statycznie zbudowanego PHP (StaticPHP) z rozszerzeniami potrzebnymi JumPHP. Micro są budowane przez workflow .github/workflows/standalone.yml i publikowane jako release standalone-<klucz> (klucz to odcisk wersji PHP, listy rozszerzeń, commita StaticPHP oraz rejestru i łatek JumPHP: tools/standalone-key.sh). Micro jest więc przebudowywane tylko wtedy, gdy zmieni się któryś z tych elementów. Ta strona wyjaśnia, jak uruchomić ten workflow na własnych runnerach (ci-runner.md, aby je zainstalować), oraz co maszyny GitHuba dawały za darmo, a czego Twoje może nie mieć.

Uruchamianie

Forge > repozytorium > Actions > standalone > Run workflow, albo z terminala (gh to gh forge w projekcie JumPHP):

gh workflow run standalone.yml -f extensions=tools/app-extensions.txt -f macos=false -f linux=false
Parametr Wartości
extensions tools/standalone-extensions.txt (gry: SDL, OpenGL, OpenAL), tools/app-extensions.txt (aplikacje desktopowe, IDE), tools/hybrid-extensions.txt zbudowane micro = własny klucz
linux true / false false: bez micro dla Linuksa (patrz „Docker” niżej); export:standalone buduje wtedy micro dla Linuksa na komputerze użytkownika
macos true / false false: bez micro dla Maca (tylko aplikacje desktopowe); bez runnera macOS zadania czekałyby w nieskończoność

Zadanie Windows trwa około 10 minut przy pobraniach w cache, 30–60 za pierwszym razem. Jego wynik: https://<forge>/<właściciel>/<repozytorium>/releases/download/standalone-<klucz>/micro-windows-x86_64.sfx.

Co miały maszyny GitHuba, a czego Twoje może nie mieć

Na GitHubie ten sam workflow „działał sam”, bo windows-latest i ubuntu-latest to obrazy przygotowane przez GitHub. Własny runner to goła maszyna. Wszystkim, co poniżej, zajmuje się workflow albo jest to powiedziane tutaj:

Obraz GitHuba Twój runner Co robi workflow / co robisz Ty
PowerShell 7 (pwsh), PHP, Composer, Git często tylko Windows PowerShell 5.1 i Git kroki działają w Windows PowerShell; PHP 8.4 i Composer są pobierane (php.net, getcomposer.org, odcisk zweryfikowany), jeśli brakuje; usr\bin z Gita trafia do PATH
Windows po angielsku język Twojego Windows (francuski...) VSLANG=1033 sprawia, że narzędzia Visual Studio mówią po angielsku: configure.js PHP czyta wyjście linkera i inaczej kończy się błędem JScript
Visual Studio 2022 do zainstalowania przez Ciebie: Build Tools 2022, obciążenie „Programowanie aplikacji klasycznych w C++” jedyna rzecz, jaką musi mieć runner Windows (obok Git for Windows). install-windows-runner.ps1 instaluje oba
Szybki dostęp do api.github.com, rzadko ograniczany to samo API odpowiada 504 lub „rate limit exceeded” pobrania StaticPHP są ponawiane 4 razy i przechowywane w %USERPROFILE%\.spc-downloads między uruchomieniami; Composer instaluje ze źródeł (--prefer-source)
actions/upload-artifact@v4, download-artifact@v4 Forgejo ich nie obsługuje („not currently supported on GHES”) na forge zadanie Windows samo publikuje micro w release (github.token zadania, API forge); zadanie release działa tylko na GitHubie
Docker w zadaniu Linux zadanie działa w kontenerze bez Dockera patrz niżej
Końce linii LF Git for Windows konwertuje na CRLF git config --global core.autocrlf false przed sklonowaniem StaticPHP (łatka jego plików opiera się na ich tekście)

Docker: gdzie jest potrzebny, a gdzie nie

  • Zadanie Windows kompiluje natywnie za pomocą Visual Studio. Nie używa Dockera, a runner Windows by tego nie potrafił (kontenery Linux pod Windows działają przez WSL2). Nic do instalowania w tym celu.
  • Zadanie Linux uruchamia docker build docker/standalone, a potem docker run StaticPHP. W kontenerze zadania nie ma Dockera, chyba że runner go udostępnia: zamontuj w zadaniu gniazdo Dockera hosta (lub dind runnera) (container.options / valid_volumes w config.yml runnera) albo użyj runnera Linux WSL2 (ci-runner.md sekcja 4), prawdziwego Linuksa z Dockerem. Bez tego uruchamiaj z linux=false: bin/jumphp export:standalone <id> --linux buduje micro dla Linuksa na komputerze, który eksportuje (około 15 minut, potem przechowywane w ~/.jumphp/standalone/).
  • Niezależnie od runnera nigdy nie kopiuj ani nie zmieniaj nazwy micro pod innym kluczem: byłoby to PHP bez właściwych rozszerzeń, a pliki wykonywalne Twoich użytkowników by się wysypywały (Call to undefined function SDL_Init()). Jeśli klucz się zmienił, micro musi zostać przebudowane.

Rozwiązywanie problemów

Dzienniki zadań czyta się na stronie runu w forge (zadanie > czerwony krok); API forge ich nie zwraca.

Objaw Przyczyna / poprawka
Zadanie key kończy się błędem po 30 s, zaraz po „Fetching the repository” kontener zadania nie rozwiązuje nazwy forge: Docker-in-Docker runnera nie ma DNS na zewnątrz. Dodaj mu: dns: [1.1.1.1, 9.9.9.9] w usłudze dind pliku compose runnera. Test: docker run --network <nowa sieć> node:20-bookworm getent hosts <forge>
Cannot find: pwsh in PATH workflow żąda Windows PowerShell (shell: powershell); stara kopia żądała pwsh. Zaktualizuj ją
configure.js ... Erreur d'exécution Microsoft JScript po „Checking for link.exe” narzędzia Visual Studio piszą w języku Windows. VSLANG=1033 (w workflow od czasu tej strony)
ERROR: bison is required widoczne po na wpół wykonanym buildzie w tym samym katalogu: StaticPHP zachowuje narzędzia msys2, ale nie dodaje ich z powrotem do PATH. Usuń spc/pkgroot, spc/source, spc/buildroot z przestrzeni roboczej i uruchom ponownie (czysta przestrzeń, jak w nowym zadaniu, działa)
Łatka StaticPHP „not patched (StaticPHP changed)” lub „Failed patch module” końce linii CRLF (core.autocrlf false i sklonuj ponownie) albo katalog źródłowy już załatany wcześniejszą próbą (usuń spc/source/php-src)
Failed to get GitHub release API info for madler/zlib / HTTP/2 504 api.github.com ogranicza lub zawodzi dla Twojego adresu. Workflow ponawia; pierwsze uruchomienie na nowej maszynie może wymagać drugiej próby. Pobrania są zachowywane: każda próba idzie dalej
GHESNotSupportedError: upload-artifact@v4 ... not currently supported używasz Forgejo: weź workflow z tego repozytorium (publikuje bez artefaktów)
Zadania macOS wiszą w „waiting”, a run nigdy się nie kończy brak runnera macOS: -f macos=false
Cannot find path ...\buildroot\bin\micro.sfx budowanie nie powiodło się wcześniej: przeczytaj linie powyżej (to one są przyczyną)

Dla agentów AI

Możesz dostać prośbę „spraw, żeby workflow standalone działał na moim runnerze”. Przeczytaj nieudany krok na stronie runu (poproś użytkownika o wklejenie, jeśli nie masz dostępu), zmieniaj workflow (musi pozostać poprawny na GitHubie: sprawdzaj github.server_url), a nie maszynę użytkownika, chyba że brakuje któregoś z wymagań powyżej (Git, Visual Studio Build Tools, Docker dla zadania Linux): powiedz wtedy o tym użytkownikowi i instaluj tylko za jego zgodą. Nigdy nie rejestruj runnera, nigdy nie zapisuj tokena w pliku, nigdy nie publikuj micro, którego nie zbudowałeś z bieżących plików poleceniami tego workflow, nigdy nie przenoś release pod inny klucz. Po udanym uruchomieniu sprawdź plik (gh release view standalone-<klucz>, pobranie odpowiadające 200) i, dla micro Windows, uruchom z nim skrypt na maszynie runnera (copy /b micro.sfx + test.php test.exe, potem test.exe: wersja PHP, extension_loaded('ffi')...).