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

Ideas about UX and performance #187

Open
dunglas opened this issue Sep 15, 2023 · 9 comments
Open

Ideas about UX and performance #187

dunglas opened this issue Sep 15, 2023 · 9 comments
Labels
enhancement New feature or request help wanted Extra attention is needed kind/workflow Issues related to workflow or environment

Comments

@dunglas
Copy link
Contributor

dunglas commented Sep 15, 2023

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 crazywhalecc added enhancement New feature or request question Further information is requested kind/workflow Issues related to workflow or environment labels Sep 15, 2023
@crazywhalecc
Copy link
Owner

crazywhalecc commented Sep 15, 2023

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
Copy link
Contributor

stloyd commented Sep 15, 2023

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
Copy link
Contributor

stloyd commented Sep 15, 2023

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.

@crazywhalecc crazywhalecc added help wanted Extra attention is needed and removed question Further information is requested labels Jan 7, 2024
@crazywhalecc crazywhalecc pinned this issue Jan 7, 2024
@simonhamp
Copy link
Contributor

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

@crazywhalecc
Copy link
Owner

crazywhalecc commented Jan 20, 2024

@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
Copy link
Contributor

  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
Copy link
Owner

crazywhalecc commented Jan 20, 2024

@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
Copy link

dixyes commented May 31, 2024

@crazywhalecc
Copy link
Owner

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.

Finally we will bring this feature to 2.3 release 🎉 #502 . And after this, we can build static PHP easier and faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed kind/workflow Issues related to workflow or environment
Projects
None yet
Development

No branches or pull requests

5 participants