Ideas about UX and performance

[dunglas]

Currently, users are encouraged to fork this repository and to set up GitHub Actions workflows in their own forks to build the static binaries they want. This causes several issues:

1. forks are hard to maintain, they must be synced from time to time to get upstream fixes and improvements
2. this means that every user must build PHP and all its dependencies again and again (which is slow and energy-greedy) while in most cases - except when using "micro combine" - downloading the resulting artifacts built once for every user would be good enough.

Now that static-php-cli will be distributed as a standalone executable and as a PHAR (#175, #179), I think that we can dramatically improve the user experience and performance.

Instead of forking the whole project, the user could just download the standalone binary and run a single command in its own GHA workflow to build its static PHP.

The project could also provide a standalone GitHub Action (instead of a whole workflow), similar to setup PHP or setup Go that will:

• download pre-built SAPI binaries including all extensions from GitHub releases if no customizations are made (super-fast)
• or download the SPC binary and build SAPIs locally if the user wants to use "micro combine" or to create a smaller binary containing less extensions

API proposal:

steps:
  - uses: crazywhalecc/setup-static-php@v1
    with:
      php-version: '8.2'
      zts: true # Optional, defaults to false
      sapi: [cli, fpm, embed, micro]
      extensions: [ opcache, sqlite ] # Optional, by default a binary containing all supported extensions will be downloaded
      combine: path/to/your/php/app/ # Optional, by default a static version of the requested SAPIs is just downloaded

In most cases, build steps will be skipped: up-to-date SAPIs can be built every night, uploaded as static-php-cli releases, and downloaded by the action. For advanced needs (custom extensions or combine), the build will still be done locally, but at least users will be sure that they are using an up-to-date version of static-php-cli. As an improvement for the custom extension or combined use case, it should also be possible to upload the content of buildroot/ to GitHub releases and let the action download and reuse up-to-date versions of .a files when doing a custom build instead of rebuilding everything.

cc @stloyd

[crazywhalecc]

Wow it's really a good proposal! Once the binary SPC is completed and the stable version 2.0.0 is released, I believe we can create a new repository as you suggested: crazywhalecc/setup-static-php, and if you @dunglas and @stloyd are open to contribute, I will add access. I'm not very familiar with the details of Actions, it would be best if you are willing to help.

But this new UX proposal also involves a lot of documentation. I could write the documentation on my tablet at any time, which is very fast to write, but it is best to list the chapters that need to be written in this part in the Docs TODO, otherwise, I tend to forget about it.

[stloyd]

I really like the idea of introducing action, while never done it before it can be an interesting project.

While we speak, I'm testing one approach where build is done periodically to see if we can easily store generated files as cache, which in fact would be one of the first steps to have such action working well.

[stloyd]

Introducting the first idea for improving the speed of builds with: #188, it generates artifacts that can be downloaded locally (or in CI) & re-used.

[simonhamp]

Keen to help on this one. Has anyone made any progress?

[crazywhalecc]

@simonhamp Actually it will be a little complicated. The problem is as follows:

1. The default extension combination provided has not been determined yet, and if the default combination is not used, it is necessary to rebuild all libraries, which is very slow. If we want to cache dependencies for different extensions, we may only be able to choose libraries that do not have lib-suggests.
2. I haven't learned how to write an Action yet (as I am currently using local builds on my own private project instead of Actions).
3. What I currently know is that FrankenPHP uses static-php-cli as a Git repository to build: https://github.com/dunglas/frankenphp/blob/main/build-static.sh
4. At present, we provide an independent binary for spc, which can replace installing PHP and cloning the repository, and can also be considered as simplifying the build process.

[simonhamp]

1. I believe the benefit of allowing folks to more easily build themselves via Actions is that it avoids the need for a default set of extensions
2. I'm happy to write the Action if no one has made a start
3. Yeh I can see the merits of @dunglas's suggestion. It would be good for NativePHP too, to be able to have Actions that just pull the latest SPC binary and get to work
4. Are you able to host stable releases of these for each platform in a fixed location?

[crazywhalecc]

@simonhamp

I have currently hosted the SPC binary of the main branch on my own server (workflow) and it should be stable, I won't change it. Additionally the release tag may not be as stable as the main branch, as it may not include an immediate fix for the download address.

Another issue is that for the definition of stable, I cannot test all the combination of supported exts and libs. I can only ensure that SPC binary can run and the download address availability is high. If we really want to ensure that the compiled PHP is stable and perfect, I'm afraid the project will never have a stable version.

The spc binary for Windows and FreeBSD can theoretically be provided, but currently my workflow is not on these two systems, so I can add them if needed in the future.

Anyway it would be even better if you could help writing Actions 👍 We already have the repo: https://github.com/static-php/setup-static-php

[dixyes]

@crazywhalecc callable-workflows了解一下 要改的东西也不多
caller: https://github.com/dixyes-bot/call-lwmbs/blob/latest/.github/workflows/daily-release.yml#L10-L19
callee: https://github.com/dixyes/lwmbs/blob/master/.github/workflows/linux-new.yml#L39-L89