New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First stab at GH workflow to build PHP in CI #178
Conversation
The build took almost 5 hours which is way too much. Locally it can take as little as 10 minutes thanks to Docker cache – let's explore leaning on that cache in Github CI. |
Separates the build pipeline of the libraries required by PHP from the build pipeline for PHP itself. The goal is to accelerate the PHP builds. Right now, rebuilding PHP may involve rebuilding all the related libraries which takes forever and makes iterating on PHP challenging. With this PR, PHP builds are much faster and perhaps could even be moved to GitHub actions. ## Building PHP in GitHub CI My [initial attempt](#178) to recompile PHP via GitHub actions failed because the task timed out after 5 hours of rebuilding PHP dependencies. I don't think GitHub actually used Docker cache between builds, but even if it did then building the libraries took extremely long time. With this PR, `npm run recompile:php:web:light:8.0` takes 4 – 5 minutes! This makes GitHub actions a much more viable build environment. <img width="607" alt="CleanShot 2023-12-03 at 21 30 33@2x" src="https://github.com/WordPress/wordpress-playground/assets/205419/7981ba97-8126-47fc-93ba-87315b54cca5"> ## Implementation details This PR ships a Makefile with a task for each library. The following libraries are covered by the Makefile and shipped with this PR as pre-built binaries: * bison2.7 * libedit * libiconv * libncurses * libopenssl * libpng16 * libsqlite3 * libxm12 * libz * libzip To remove the pre-built libraries on your computer, run: ```bash cd packages/php-wasm/compile/ make clean ``` To rebuild the libraries on your computer, run: ```bash cd packages/php-wasm/compile/ make all ``` ## Follow-up work * Create a GitHub task to regenerate outdated PHP builds (e.g. when `8.0.9` is shipped, but `8.0.11` is available) * Explore moving the pre-built PHP `.wasm` from tracked git files into GitHub releases or any other GitHub facility that enables shipping files. This will likely require adding some kind of `npm run update-php` local task that will automatically run when building `wasm-wordpress-net` and after running `npm install`. ## Testing instructions * Confirm the CI tests passed * Run the following commands to confirm the build procedure works for all the libraries covered by Makefile: ```bash cd packages/php-wasm/compile/ make clean make all ``` * Rebuild all the PHP versions locally * `recompile:php:web` * `recompile:php:node` * Run `npm run dev` and confirm the local website still works * Run `npm run test` and confirm the unit tests still pass * Run `npm run e2e` and confirm the E2E tests still pass
I've got some experience with GitHub CI if you want some eyes on this. |
This would be super helpful @moonmeister! A workflow to build and commit all PHP versions for a given configuration (node, web, kitchen sink) would be a super useful addition. It would unlock auto-updating PHP builds as the new versions are released. Also, good news – the build should take much less time these days, now that prebuilt dependencies are shipped with the repo. |
Sweet @adamziel, question...I come from a world where build artifacts should rarely be committed back to a repo. What's the reasoning on this? Is there a better location like GH releases where we can place these artifacts? |
Only that it was an easy way to run the project with Ideally, both PHP and WordPress would live in GitHub releases and |
Test PR to launch an automated PHP build workflow