Skip to content
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

Closed
wants to merge 5 commits into from
Closed

Conversation

adamziel
Copy link
Collaborator

Test PR to launch an automated PHP build workflow

@adamziel
Copy link
Collaborator Author

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.

adamziel added a commit that referenced this pull request Dec 6, 2023
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
@moonmeister
Copy link
Contributor

I've got some experience with GitHub CI if you want some eyes on this.

@adamziel
Copy link
Collaborator Author

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.

@moonmeister
Copy link
Contributor

moonmeister commented Dec 21, 2023

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?

@adamziel
Copy link
Collaborator Author

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 git clone && npm run dev without building PHP locally.

Ideally, both PHP and WordPress would live in GitHub releases and npm run dev would pull the relevant release – which could be the latest one, but could also be an older release if you happen to be on a branch or debugging something with a bisect. This is a more complex flow and I didn't build it, but it would still be lovely to have if if you're up for a challenge.

@adamziel adamziel closed this May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants