PHP micro'sunu kendi runner'larınızda derlemek (`standalone` workflow'u)

bin/jumphp export:standalone ve app:export, bir oyunu ya da uygulamayı bir micro'ya yapıştırır: JumPHP'nin ihtiyaç duyduğu eklentilerle statik olarak derlenmiş bir PHP (StaticPHP). Micro'lar .github/workflows/standalone.yml workflow'u tarafından derlenir ve standalone-<anahtar> sürümü olarak yayımlanır (anahtar; PHP sürümünün, eklenti listesinin, StaticPHP'nin commit'inin ve JumPHP'nin kayıt defterinin ve yamalarının parmak izidir: tools/standalone-key.sh). Bu nedenle bir micro yalnızca bu öğelerden biri değişirse yeniden derlenir. Bu sayfa, bu workflow'u kendi runner'larınızda nasıl çalıştıracağınızı (ci-runner.md kurulum için) ve GitHub'ın makinelerinin size ücretsiz verdiği, ama sizinkilerde olmayabilecek şeyleri anlatır.

Başlatmak

Forge > depo > Actions > standalone > Run workflow, ya da bir terminalden (bir JumPHP projesinde gh, forge'unkidir):

gh workflow run standalone.yml -f extensions=tools/app-extensions.txt -f macos=false -f linux=false

Girdi	Değerler
`extensions`	`tools/standalone-extensions.txt` (oyunlar: SDL, OpenGL, OpenAL), `tools/app-extensions.txt` (masaüstü uygulamaları, IDE), `tools/hybrid-extensions.txt`	derlenen micro = kendi anahtarı
`linux`	`true` / `false`	`false`: Linux micro'su yok (aşağıdaki « Docker » bölümüne bakın); `export:standalone` o zaman Linux micro'sunu kullanıcının bilgisayarında derler
`macos`	`true` / `false`	`false`: Mac micro'su yok (yalnızca masaüstü uygulamaları); macOS runner'ı yoksa işler sonsuza dek beklerdi

Windows işi, indirmeler önbellekteyken yaklaşık 10 dakika, en ilk seferde 30 ila 60 dakika sürer. Çıktısı: https://<forge>/<sahip>/<depo>/releases/download/standalone-<anahtar>/micro-windows-x86_64.sfx.

GitHub'ın makinelerinde olup sizinkilerde olmayabilecekler

GitHub'da aynı workflow « kendi kendine çalışıyordu », çünkü windows-latest ve ubuntu-latest GitHub tarafından hazırlanmış imajlardır. Sizin runner'ınız çıplak bir makinedir. Aşağıdakilerin hepsi ya workflow tarafından yönetilir ya da burada belirtilir:

GitHub'ın imajı	Sizin runner'ınız	Workflow'un yaptığı / sizin yapacağınız
PowerShell 7 (`pwsh`), PHP, Composer, Git	çoğunlukla yalnızca Windows PowerShell 5.1 ve Git	adımlar Windows PowerShell'de çalışır; eksikse PHP 8.4 ve Composer indirilir (php.net, getcomposer.org, parmak izi doğrulanır); Git'in `usr\bin` dizini PATH'e eklenir
İngilizce Windows	Windows'unuzun dili (Fransızca...)	`VSLANG=1033`, Visual Studio araçlarını İngilizce konuşturur: PHP'nin `configure.js` dosyası bağlayıcının çıktısını okur ve aksi halde bir JScript hatasıyla durur
Visual Studio 2022	sizin kurmanız gerekir: Build Tools 2022, « C++ ile masaüstü geliştirme » iş yükü	bir Windows runner'ının sahip olması gereken tek şey (Git for Windows ile birlikte). install-windows-runner.ps1 ikisini de kurar
`api.github.com`'a hızlı erişim, nadiren sınırlanır	aynı API `504` ya da « rate limit exceeded » döndürür	StaticPHP indirmeleri 4 kez yeniden denenir ve iki çalıştırma arasında `%USERPROFILE%\.spc-downloads` içinde saklanır; Composer kaynaklardan kurar (`--prefer-source`)
`actions/upload-artifact@v4`, `download-artifact@v4`	Forgejo bunları desteklemez (« not currently supported on GHES »)	bir forge'da Windows işi micro'yu sürüme kendisi yayımlar (işin `github.token`'ı, forge'un API'si); `release` işi yalnızca GitHub'da çalışır
Linux işinde Docker	iş, Docker'sız bir konteynerde çalışır	aşağıya bakın
LF satır sonları	Git for Windows bunları CRLF'ye çevirir	StaticPHP'yi klonlamadan önce `git config --global core.autocrlf false` (dosyalarına uygulanan bir yama metinlerine dayanır)

Docker: nerede gerekli, nerede değil

Windows işi Visual Studio ile yerel olarak derler. Docker kullanmaz ve bir Windows runner'ı bunu yapamazdı (Windows altındaki Linux konteynerleri WSL2 üzerinden çalışır). Bunun için kurulacak bir şey yok.
Linux işi docker build docker/standalone komutunu, ardından StaticPHP'nin docker run komutunu çalıştırır. Bir iş konteynerinde Docker yoktur, runner bir tane vermedikçe: ana makinenin Docker soketini (ya da runner'ın dind'ini) işe bağlayın (runner'ın config.yml dosyasında container.options / valid_volumes), ya da WSL2 Linux runner'ını kullanın (ci-runner.md bölüm 4), Docker'lı gerçek bir Linux. Bunlar olmadan linux=false ile çalıştırın: bin/jumphp export:standalone <id> --linux, Linux micro'sunu dışa aktaran bilgisayarda derler (yaklaşık 15 dakika, ardından ~/.jumphp/standalone/ içinde saklanır).
Hangi runner olursa olsun, bir micro'yu asla başka bir anahtar altında kopyalamayın ya da yeniden adlandırmayın: bu, doğru eklentileri olmayan bir PHP olurdu ve kullanıcılarınızın çalıştırılabilir dosyaları çökerdi (Call to undefined function SDL_Init()). Anahtar değiştiyse micro yeniden derlenmelidir.

Sorun giderme

İş günlükleri forge'daki çalıştırma sayfasında okunur (iş > kırmızı adım); forge'un API'si bunları döndürmez.

Belirti	Neden / çözüm
`key` işi, « Fetching the repository » hemen sonrasında 30 sn içinde başarısız olur	iş konteyneri forge'un adını çözemiyor: runner'ın Docker-in-Docker'ının dışarıya DNS'i yok. Ona bir tane verin: runner'ın compose dosyasındaki `dind` servisinde `dns: [1.1.1.1, 9.9.9.9]`. Test: `docker run --network <yeni bir ağ> node:20-bookworm getent hosts <forge>`
`Cannot find: pwsh in PATH`	workflow Windows PowerShell ister (`shell: powershell`); eski bir kopya `pwsh` istiyordu. Güncelleyin
« Checking for link.exe » sonrasında `configure.js ... Erreur d'exécution Microsoft JScript`	Visual Studio araçları Windows'un diliyle yazar. `VSLANG=1033` (bu sayfadan beri workflow'da)
`ERROR: bison is required`	aynı klasörde yarım kalmış bir derlemeden sonra görülür: StaticPHP msys2 araçlarını saklar ama PATH'e geri koymaz. Çalışma alanından `spc/pkgroot`, `spc/source`, `spc/buildroot` dizinlerini silin ve yeniden başlatın (yeni bir işinki gibi temiz bir alan çalışır)
Bir StaticPHP yaması « not patched (StaticPHP changed) » ya da « Failed patch module »	CRLF satır sonları (`core.autocrlf false` ve yeniden klonlama), ya da önceki bir denemeyle zaten yamalanmış bir kaynak klasörü (`spc/source/php-src` dizinini silin)
`Failed to get GitHub release API info for madler/zlib` / `HTTP/2 504`	`api.github.com` adresiniz için sınırlıyor ya da başarısız oluyor. Workflow yeniden dener; yeni bir makinedeki ilk çalıştırma ikinci bir deneme gerektirebilir. İndirmeler saklanır: her deneme biraz daha ileri gider
`GHESNotSupportedError: upload-artifact@v4 ... not currently supported`	Forgejo kullanıyorsunuz: bu deponun workflow'unu alın (artifact olmadan yayımlar)
macOS işleri « waiting » durumunda kalır ve çalıştırma hiç bitmez	macOS runner'ı yok: `-f macos=false`
`Cannot find path ...\buildroot\bin\micro.sfx`	derleme daha önce başarısız oldu: üstündeki satırları okuyun (neden onlardır)

Yapay zekâ ajanları için

Sizden « standalone workflow'unu runner'ımda çalıştırmanız » istenebilir. Çalıştırma sayfasında başarısız olan adımı okuyun (erişemiyorsanız kullanıcıdan yapıştırmasını isteyin), workflow'u değiştirin (GitHub'da geçerli kalmalıdır: github.server_url'yi test edin), kullanıcının makinesini değil; eksik olan yukarıdaki ön koşullardan biri değilse (Git, Visual Studio Build Tools, Linux işi için Docker): o durumda bunu kullanıcıya söyleyin ve yalnızca evet derse kurun. Asla bir runner kaydetmeyin, asla bir dosyaya belirteç yazmayın, bu workflow'un komutlarıyla mevcut dosyalardan kendi derlemediğiniz bir micro'yu asla yayımlamayın, bir sürümü asla başka bir anahtar altına taşımayın. Başarılı bir çalıştırmadan sonra dosyayı doğrulayın (gh release view standalone-<anahtar>, 200 yanıtı veren bir indirme) ve bir Windows micro'su için, runner'ın makinesinde onunla bir betik çalıştırın (copy /b micro.sfx + test.php test.exe, ardından test.exe: PHP sürümü, extension_loaded('ffi')...).