paketo-buildpacks/php

A Cloud Native Buildpack for PHP

Paketo Buildpack for PHP

gcr.io/paketo-buildpacks/php

The PHP Paketo Buildpack provides a set of collaborating buildpacks that enable the building of a PHP-based application. These buildpacks include:

• PHP Dist CNB
• PHP HTTPD CNB
• PHP Nginx CNB
• PHP Built-in Server CNB
• PHP FPM CNB
• PHP Start CNB
• PHP Redis Session Handler CNB
• PHP Memcached Session Handler CNB
• Composer CNB
• Composer Install CNB
• Apache HTTPD CNB
• NGINX CNB

The buildpack supports building PHP console and web applications. Web applications can be run on either the built-in PHP webserver, Apache HTTPD or NGINX. The buildpack also provides optional support for the utilization of Composer as a package manager.

Usage examples can be found in the samples repository under the php directory.

This buildpack also includes the following utility buildpacks:

• Procfile CNB
• Environment Variables CNB
• Image Labels CNB
• CA Certificates CNB

The PHP buildpack is compatible with the following builder(s):

• Paketo Jammy Full Builder
• Paketo Bionic Full Builder

Docs

Check out the PHP Paketo Buildpack docs for more information.

php's Issues

Add Procfile to group order

We should add the Procfile Paketo Buildpack to the PHP Language family buildpack so that users can define start commands via a Procfile (see paketo-buildpacks/rfcs#7)

Buildpack support for Symfony 5 demo app

I haven't been able to get the PHP buildpack to build the Symfony 5 demo app. Expected behaviour is that the buildpack should be able to build this app, as it's apparently a canonical Symfony app and users want support for the framework (see #3)

Repro steps:

1. Clone the symfony 5 demo app
2. Update dependencies in the lock file composer update --no-install
3. Add a buildpack.yml containing:

   ---
   composer:
     vendor_directory: "vendor"
   
   php:
     webdirectory: "public"
   

4. Build the app

   pack build symfony-demo -b gcr.io/paketo-buildpacks/php --env APP_ENV=prod
   

Result:
Build fails with output

pack build symfony-demo -b gcr.io/paketo-buildpacks/php --env APP_ENV=prod
base: Pulling from paketobuildpacks/builder
Digest: sha256:95015c909b3031bb618123866447f2c440d5e56e9dca3ab4fe7cb432b88941a3
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:155ee4b4389fa88b8b9bd5444601417218b3da44e491b1aad8c8b6c2365e7909
Status: Image is up to date for paketobuildpacks/run:base-cnb
latest: Pulling from paketo-buildpacks/php
Digest: sha256:9e3d9c0c192773d559fbf232667fb2c82425240d9f36c7fbd1354a6c991b433f
Status: Image is up to date for gcr.io/paketo-buildpacks/php:latest
0.9.3: Pulling from buildpacksio/lifecycle
Digest: sha256:bc253af2edf1577717618cb3a95f0f16bb18fc9e804efbcc1b85f657d931a757
Status: Image is up to date for buildpacksio/lifecycle:0.9.3
===> DETECTING
[detector] 3 of 5 buildpacks participating
paketo-buildpacks/php-dist     0.0.208
paketo-buildpacks/php-composer 0.0.127
paketo-buildpacks/php-web      0.0.133
===> ANALYZING
[analyzer] Previous image with name "symfony-demo" not found
===> RESTORING
===> BUILDING
[builder] Paketo PHP Buildpack 0.0.208
  Resolving PHP version
    Candidate version sources (in priority order):
      composer.lock    -> "^7.2.9"
      default-versions -> "7.2.*"

[builder]     Selected PHP version (using composer.lock): 7.4.9
[builder]
  Executing build process
[builder]     Installing PHP 7.4.9
[builder]       Completed in 4.168s

  Configuring environment
[builder]     MIBDIRS           -> "/layers/paketo-buildpacks_php-dist/php/mibs"
    PATH              -> "/layers/paketo-buildpacks_php-dist/php/sbin:$PATH"
    PHP_API           -> "20190902"
    PHP_EXTENSION_DIR -> "/layers/paketo-buildpacks_php-dist/php/lib/php/extensions/no-debug-non-zts-20190902"
    PHP_HOME          -> "/layers/paketo-buildpacks_php-dist/php"

[builder]
Paketo PHP Composer Buildpack 0.0.127
   1.10.10: Contributing to layer
[builder]     Downloading from https://buildpacks.cloudfoundry.org/dependencies/composer/composer_1.10.10_linux_noarch_any-stack_8f16aa77.phar
[builder]     Verifying checksum
[builder]     Expanding to /layers/paketo-buildpacks_php-composer/composer
[builder]   PHP Composer Cache e57a3520f2fcb109f78c013afc32e8c9178ebda4c9b9e14a706c666172c8902a: Contributing to layer
[builder] php: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory
[builder] exit status 127
[builder] ERROR: failed to build: exit status 106
ERROR: failed to build: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 145

Implement PHP RFC 0001: Restructure PHP

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

This issue serves as a meta-issue for tracking the implementation all of the restructure work amongst the implementation buildpacks and language family.

Issues

• #472

---

1. Deprecation warning for buildpack.yml usage (Parallelizable)

• paketo-buildpacks/php-web#216
• paketo-buildpacks/php-dist#329
• paketo-buildpacks/php-composer#265

---

2. PHP Builtin Server Simple Use case

• paketo-buildpacks/php-dist#324
• Waiting for release - paketo-buildpacks/php-builtin-server#1

---

3. Implement initial php-fpm buildpack

• paketo-buildpacks/php-fpm#3

---

4. NGINX and HTTPD Web servers (parallelizable)

• paketo-buildpacks/php-httpd#2
• RFC for #503
• paketo-buildpacks/php-httpd#4
• paketo-buildpacks/php-start#1
• #479
• paketo-buildpacks/php-nginx#2
• paketo-buildpacks/php-start#2
  These may require changes to php-dist and/or php-fpm buildpacks

---

5. Modularize composer and substitute in the language family (sequential)

• paketo-buildpacks/composer#12
• In Progress - paketo-buildpacks/composer-install#4
• #475

---

6. Optional session handlers (parallelizable)

• https://github.com/paketo-buildpacks/php-memcached-session-handler#1
• paketo-buildpacks/php-redis-session-handler#1

---

7. Swap new buildpacks into the language family order groups, finish up

• #483
• #524
• paketo-buildpacks/paketo-website#370

---

8. Future optimizations (can be done outside of rewrite):

• paketo-buildpacks/nginx#358
• paketo-buildpacks/php-fpm#26

Restructure buildpack: Create php-nginx buildpack

Context

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

Currently, the PHP Web buildpack is responsible for configuring and running PHP applications across built-in PHP servers, HTTPD, NGINX, as well as supporting FPM process managers. The goal of this issue is to separate the concerns within PHP Web into individual buildpacks.

Issue

This issue is to add a new buildpack, named php-nginx, which will be responsible for setting up NGINX to serve PHP applications. This issue is blocked on https://github.com/paketo-buildpacks/php/issues/476.

Logic to support the NGINX server setup currently lives within the PHP Web buildpack and should be moved into this new buildpack.

• API: The buildpack should provide none and require php, require php-fpm, and require nginx at launch-time.

• The buildpack will be responsible for generating an nginx.conf file

• The buildpack should contribute NGINX-specific FPM configurations to the location set up in in the PHP FPM buildpack. This configuration should at a minimum include setting the www/listen value to the same value as the FPM Socket in the NGINX config. (See this example in PHP web, as well as this example)

• It is also responsible for setting the start command of type web to start the NGINX server, as well as PHP FPM.

• In order for this buildpack to pass detection, users must declare their intention to use NGINX as their server of choice. Following #472, an option to accomplish this besides using a buildpack.yml should be enumerated to cover this case.

• Packit: This buildpack should be written using the packit library.

• Buildpack API Version: This buildpack should be written using Buildpack API 0.7

• Add a [[buildpack.licences]] section to the buildpack.toml.

• README: Make sure a README is added that conveys context about the buildpack in a manner consistent with other Paketo buildpacks.

• Direct processes: Use direct processes and exec.d where applicable.

This issue can be transferred to the appropriate repository (paketo-buildpacks/php-nginx), once it has been created.

Acceptance

1. I can successfully build a PHP app that uses an NGINX such as the Paketo PHP NGINX sample app, with PHP Dist, the new PHP-FPM buildpack, the NGINX buildpack, this new PHP NGINX buildpack. During the build, I can see logs that show the app is run with the NGINX server and starts FPM. I can also run the container and curl the app and see Powered By Paketo Buildpacks.

Week of 2022/11/30 - PHP Buildpack releases

Sample App (https://paketo.io/docs/howto/php/#build-a-sample-app) is failing

What happened?

The example from the coumenation is failing

• What were you attempting to do?

Try it out

• What did you expect to happen?

Build one sample app

• What was the actual behavior? Please provide log output, if possible.

Error during build

Build Configuration

(curl -sSL "https://github.com/buildpacks/pack/releases/download/v0.25.0/pack-v0.25.0-linux.tgz" | sudo tar -C /usr/local/bin/ --no-same-owner -xzv pack)

rm -Rf test-pack
git clone https://github.com/paketo-buildpacks/samples test-pack
pack build my-app --buildpack paketo-buildpacks/php \
  -v \
  --path test-pack/php \
  --builder paketobuildpacks/builder:full

gives

[root@localhost helm-ezplatform]# pack build my-app --buildpack paketo-buildpacks/php \
  -v \
  --path test-pack/php \
  --builder paketobuildpacks/builder:full
Builder paketobuildpacks/builder:full is trusted
Pulling image index.docker.io/paketobuildpacks/builder:full
9fe53718107f: Already exists 
83525de54a98: Already exists 
97671025c60a: Already exists 
0c99c7dee7c2: Already exists 
b1c33401cf49: Already exists 
1625b8c23c13: Already exists 
357fefdf9bc9: Already exists 
f1660bede629: Already exists 
1fd845cab58e: Already exists 
4bbc170ef914: Already exists 
e32f334acaba: Already exists 
7192b9c7fefd: Already exists 
9172af956f63: Already exists 
bd7ca53f007e: Already exists 
52a2f344e73f: Already exists 
1060137bb4a4: Already exists 
bf98b13c2363: Already exists 
e1fda517b9af: Already exists 
6f1a665c5f18: Already exists 
53e087531167: Already exists 
af52a832ca5c: Already exists 
93d8352efdc1: Already exists 
806680c5da03: Already exists 
18dc6e7db49c: Already exists 
457f86152e96: Already exists 
c0c1d5d746a6: Already exists 
b17d081eb590: Already exists 
edf4cf392bdc: Already exists 
ff7466eef076: Already exists 
1fe2e724d812: Already exists 
d0ae5b2d71ef: Already exists 
24aa8aedaa57: Already exists 
3363e5573282: Already exists 
842ccf817908: Already exists 
794d7d79ad92: Already exists 
22e500e6fc27: Already exists 
d9fd1aa3b6f8: Already exists 
40655ba38256: Already exists 
cdcec7a546b2: Already exists 
93fe2502b880: Already exists 
92650d7d6188: Already exists 
94ad14ff029b: Already exists 
865433ffe81e: Already exists 
cc4ffd7e32f0: Already exists 
3fc0e455b2c0: Already exists 
ba782ce0626e: Already exists 
0686acdf8336: Already exists 
a76468ec0151: Already exists 
b6e8164c9b8b: Already exists 
e114005d8e3d: Already exists 
5e140aefe5bd: Already exists 
f1ca3fe59707: Already exists 
1e1d033f358e: Already exists 
a1861869c383: Already exists 
d96741ddf549: Already exists 
3e99a981936e: Already exists 
69b37fc50fda: Already exists 
e31de542bdef: Already exists 
bfb7b3fe8b36: Already exists 
8d809e3a6c52: Already exists 
92f6bec0386a: Already exists 
9b5666b6173a: Already exists 
efe3eae6c3a2: Already exists 
5b5bdd11bbdb: Already exists 
5e47452ca0cc: Already exists 
f0709036dc8a: Already exists 
da0a24c3ec07: Already exists 
f2fb409ec114: Already exists 
15964dff2ce4: Already exists 
ff6aa36572d2: Already exists 
4b35802e4af5: Already exists 
814a0dbf2ea6: Already exists 
4340630611e9: Already exists 
93db30b468f4: Already exists 
197959803628: Already exists 
836722c4feaa: Already exists 
b6bf4d3247d4: Already exists 
7e47675dad26: Already exists 
70663e2ce7f8: Already exists 
1d1a4a886e5a: Already exists 
10fd3078ed43: Already exists 
4088f544d733: Already exists 
6585c7ca3dd5: Already exists 
3c5884b39c12: Already exists 
76fc7ab6e709: Already exists 
e02a34461639: Already exists 
e38233ca5e81: Already exists 
288c3fa81b55: Already exists 
3cb5b33fc004: Already exists 
a2250b7a7cd6: Already exists 
af297f843218: Already exists 
de8e33be2dd6: Already exists 
2fc553cc43f6: Already exists 
f8ed84f660a5: Already exists 
37003c2985c5: Already exists 
ec600544af70: Already exists 
6c8d4e7d0e48: Already exists 
bc0d63ba379f: Already exists 
8be1b637ea33: Already exists 
f03e671f7e00: Already exists 
553b1439893d: Already exists 
41ddae9586ef: Already exists 
1f48e6d7c828: Already exists 
273978fd99f5: Already exists 
4f4fb700ef54: Already exists 
6e6bc4e320de: Download complete 
Selected run image index.docker.io/paketobuildpacks/run:full-cnb
Pulling image index.docker.io/paketobuildpacks/run:full-cnb
17bcc518f54b: Already exists 
83525de54a98: Already exists 
e23e9712e6de: Already exists 
142ccce008b9: Already exists 
20c84f2fb062: Download complete 
Setting custom order
Creating builder with the following buildpacks:
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
-> paketo-buildpacks/[email protected]
Using build cache volume pack-cache-library_my-app_latest-cbd6ecf04229.build
Running the creator on OS linux with:
Container Settings:
  Args: /cnb/lifecycle/creator -daemon -launch-cache /launch-cache -log-level debug -app /workspace -cache-dir /cache -run-image index.docker.io/paketobuildpacks/run:full-cnb my-app
  System Envs: CNB_PLATFORM_API=0.8
  Image: pack.local/builder/6363686865676c68726e:latest
  User: root
  Labels: map[author:pack]
Host Settings:
  Binds: pack-cache-library_my-app_latest-cbd6ecf04229.build:/cache /var/run/docker.sock:/var/run/docker.sock pack-cache-library_my-app_latest-cbd6ecf04229.launch:/launch-cache pack-layers-wtvbwsgrea:/layers pack-app-ueguiyxmar:/workspace
  Network Mode: 
===> ANALYZING
Analyzing image "7e7dea65b6f95ac5b6f98cd7f778c3e50f20c881f5536173a056ee206555522d"
Restoring data for SBOM from previous image
Retrieving previous image SBOM layer for "sha256:7a248c3d8cd3ff3e21a55dead2b7935baf1f31a03855b8f9afe0036dfb984222"
Analyzing image "20c84f2fb0625e4b32f3a39385559ad7225f4d7a697ef8d4a8f6b0cd636c9555"
===> DETECTING
======== Output: paketo-buildpacks/[email protected] ========
no composer.json found
======== Output: paketo-buildpacks/[email protected] ========
failed
======== Output: paketo-buildpacks/[email protected] ========
no service bindings of type `php-memcached-session` provided
======== Output: paketo-buildpacks/[email protected] ========
no service bindings of type `php-redis-session` provided
======== Results ========
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
fail: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
======== Output: paketo-buildpacks/[email protected] ========
no composer.json found
======== Output: paketo-buildpacks/[email protected] ========
failed
======== Output: paketo-buildpacks/[email protected] ========
no service bindings of type `php-memcached-session` provided
======== Output: paketo-buildpacks/[email protected] ========
no service bindings of type `php-redis-session` provided
======== Results ========
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
fail: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
======== Output: paketo-buildpacks/[email protected] ========
no composer.json found
======== Output: paketo-buildpacks/[email protected] ========
no *.php files found at: /workspace
======== Output: paketo-buildpacks/[email protected] ========
no service bindings of type `php-memcached-session` provided
======== Output: paketo-buildpacks/[email protected] ========
no service bindings of type `php-redis-session` provided
======== Results ========
pass: paketo-buildpacks/[email protected]
pass: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
fail: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
skip: paketo-buildpacks/[email protected]
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
ERROR: failed to build: executing lifecycle: failed with status code: 20

Checklist

• [ x] I have included log output.
• [ x] The log output includes an error message.
• [ x] I have included steps for reproduction.

Failure: Create Draft Release workflow

Create Draft Release workflow failed.

Bug: Fail to run Laravel app on Jammy

Expected Behavior

I can run the resulting Laravel app image generating with the buildpacks on the Jammy stack.

Current Behavior

When running docker run --rm -p 8080:8080 --env PORT=8080 jammy-laravel on my app image, it fails when I curl the application:

The stream or file "/workspace/storage/logs/laravel.log" could not be opened in append mode: Failed to open stream: Permission denied
The exception occurred while attempting to log: The stream or file "/workspace/storage/logs/laravel.log" could not be opened in append mode: Failed to open stream: Permission denied
...

Possible Solution

This may be resolved by paketo-buildpacks/composer-install#46, but the issue is that we are trying to write to /workspace at run-time which is not allowed due to paketo-buildpacks/rfcs#188. This may not be fixable at all without a workaround, since PHP wants to stream logs

Steps to Reproduce

1. Generate a Laravel app (composer create-project laravel/laravel ./example-laravel-app), add extensions (fileinfo, curl, openssl) to .php.ini.d/custom.ini
2. Build:

pack build jammy-laravel -b paketo-buildpacks/php -e BP_PHP_SERVER=httpd -e BP_PHP_WEB_DIR=public --builder paketobuildpacks/builder-jammy-buildpackless-full

3. Run app: docker run --rm -p 8080:8080 --env PORT=8080 jammy-laravel
4. curl localhost:8080

Motivations

Building and reaching a Laravel app with the same steps works on Bionic, but fails on Jammy. Now that we support Jammy Jellyfish with the PHP buildpack, this experience should work.

Support for app initialization configuration

What happened?

I included a .profile script at the root of my php app to set initialization configuration. This is supported in v2 buildpacks, as documented here in the Configure App Initialization section. When I pack build this app with the PHP buildpack, the desired environment variable isn't set at app initialization time.

Please provide some details about the task you are trying to accomplish and
what went wrong.

• What were you attempting to do?
  Use a .profile script (or .profile.d directory of scripts) to set some behaviour at app start time.

• What did you expect to happen?
  The .profile script would run before app start, making the environment variable available at run time.

• What was the actual behavior? Please provide log output, if possible.
  The environment variable was not set automatically

Build Configuration

Please provide some details about your build configuration.

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.

pack --version
0.14.0+git-62ea2e6.build-1341

• What buildpacks are you using? Please include versions.

gcr.io/paketo-buildpacks/php:0.0.11

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

paketobuildpacks/builder:0.1.30-full

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

See this app

Checklist

Please confirm the following:

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Implement RFC0052: Graceful Stack Upgrades

RFC

Summary

All Paketo Buildpacks should support graceful stack upgrades between the current Bionic and Jammy stacks. For most buildpacks, this should not require any changes, but for some buildpacks, layers created in previous builds that would normally be reused should be recreated if the stack ID changes.

Action Item

Consider what types of buildpacks would be impacted by a stack upgrade and make any relevant changes that would help to mitigate issues caused by that upgrade. If there is no work to be done, please comment on this issue explaining the context that helped to arrive at that conclusion.

Restructure: Update Language Family Order Groups

As per PHP RFCs we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

Note: This issue is up to date with the PHP RFCs as of commit 6dc7377, and deprecates issues #475 and #483.

Blocked

This issue is blocked on the release of all buildpacks listed in the New Buildpacks section below.

Ensure that paketo-buildpacks/php-dist#376 is done and release for inclusion into this release.

New Buildpacks

This issue is to update the language family order groupings to make use of newly added PHP buildpacks:

• php-fpm

• php-httpd

• php-nginx

• php-builtin-server

• php-memcached-session-handler (optional = true)
  paketo-buildpacks/php-memcached-session-handler#1

• php-redis-session-handler (optional = true)
  paketo-buildpacks/php-redis-session-handler#1

• composer (optional = true)

• composer-install (optional = true)
  paketo-buildpacks/composer-install#4

• php-start

In addition:

• Remove unused buildpacks
• Add new integration tests and fixtures as needed
• Update the README accordingly
• remove buildpack.yml warnings and support from PHP Dist before release

Acceptance

Use cases

With the new language family buildpack, I can successfully:

• Build an image to run HTTPD web server with php
• Build an image to run Nginx web server with php
• Build an image to run Built-in php web server
• Build an image to run FPM process manager
• Build an image to run a PHP CLI script using Procfile.
• Optionally use composer as application level package manager
• Optionally use memcached as session handler
• Optionally use redis as session handler

Order Groups

As of commit 2f024a5, the PHP buildpack had one single order group. With the PHP RFCs there should be a total of three order groups, shown here in their entirety.

[[order]] # HTTPD web server

  [[order.group]]
    id = "paketo-buildpacks/ca-certificates"
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/composer"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/composer-install"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/httpd"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-fpm"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-httpd"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-memcached-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-redis-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-start"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = ""


  [[order.group]]
    id = "paketo-buildpacks/environment-variables"
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/image-labels"
    optional = true

[[order]] # Nginx web server

  [[order.group]]
    id = "paketo-buildpacks/ca-certificates"
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/composer"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/composer-install"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/nginx"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-fpm"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-nginx"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-memcached-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-redis-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-start"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/environment-variables"
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/image-labels"
    optional = true

[[order]] # Built-in web server (web), FPM (php-fpm) & Script (Procfile)

  [[order.group]]
    id = "paketo-buildpacks/ca-certificates"
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/composer"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/composer-install"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-fpm"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-builtin-server"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-memcached-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-redis-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/environment-variables"
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/image-labels"
    optional = true

PHP Paketo Language Family Buildpacks should receive implementation buildpack updates

Context
We should set up our pipelines to start updating the language family CNB level buildpack.toml anytime there is a new version of one of its Implementation Paketo Buildpacks.

Proposal
Attempt to use Github Actions to start auto-PRing implementation CNB versions in the Paketo PHP Language family buildpacks. If pipelines pass, the update PR should be automatically merged.

Acceptance Criteria
GIVEN any implementation CNB in a language family CNB(PHP) is updated
THEN I see that there is a PR to the language family CNB with the implementation CNB updates
AND when the pipelines pass
THEN I see that the PR has been auto-merged

Notes
Here is a concourse task that is used bump cnb dependencies:
https://github.com/cloudfoundry/buildpacks-ci/tree/ce29842908d77018051422560db38df9fdbfa33c/tasks/cnb/update-cnb-dependency

Add top level [[buildpack.licenses]] field

What happened?

We should add the top level [[buildpack.licenses]] field to buildpack.toml (and all implementation buildpacks) so users can see the buildpack's license through an app image's bill of materials.

Introduce a PHP Start buildpack

Context

Part of the implementation of #485 includes the creation of a PHP HTTPD and PHP NGINX buildpacks. These buildpacks are responsible for the following:

• Set up web server configuration
• Set up any additional FPM server-specific configuration
• Set the server start command
• Set the FPM start command

As it stands now, the PHP Web buildpack handles all of this logic. The HTTPD/NGINX parts of that buildpack use something called the procmgr from the buildpack to run multiple start commands (one for server and one for FPM).

It's likely that a similar package to procmgr will need to be re-implemented in the new buildpacks to achieve the same double-start command behaviour.

Issue

This issue proposes separating the responsibility of setting the start commands for the web servers and FPM into a separate buildpack called PHP Start.

Separating this functionality into its own buildpack will mean that the procmgr code will not be duplicated across two buildpacks needlessly. It also will lead to far less complexity in the PHP HTTPD/NGINX buildpacks, which will be responsible just for setting up configuration. This also follows the modular buildpack pattern we see in other language families in Paketo.

Outcomes

The outcome of this issue should be to come to a consensus as to whether or not we should introduce a PHP Start buildpack to the PHP Restructure work, and then depending on the result, create an addendum RFC to https://github.com/paketo-buildpacks/rfcs/blob/main/text/php/0001-restructure.md to document the decision.

Migrate docs into a Hugo module

In order to locate Paketo documentation closer to the code it documents, we can migrate the docs for this language family from where they currently live in the paketo website repo into a Hugo module that sits inside this repository.

For an example of this, see the Hugo module that sits inside the Paketo Dotnet Core language family repo.

To do this successfully, we need

• A workflow that automatically tags a release of the docs module when a release is cut on this language family repo. This has been handled in a PR to the centralized Paketo github-config repository
• A Hugo module inside this language family repo (This module needs to have the name github.com/paketo-buildpacks/<name of this repo>/docs in order for the existing automation to work properly.) It should have the same structure as the Hugo module inside the dotnet-core repo.
• An additional entry in the go.mod of the paketo-website repo for this repo's docs module
• An additional [[module.imports.mounts]]in the paketo-website repo's hugo config.toml that mounts the content in this repo's docs module into the proper path in the site's directory structure. That path should match the path to the existing docs file in that repo (Hint: The docs file is probably in here).

Container won't start because of missing library

I tried to build three different sources using pack and this PHP buildpack, but all resulting images fail to start or even fail to build with the following error message:

php: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

• Freshly cloned Laravel app with vendored dependencies => Build successful, failed to start
• Freshly cloned Laravel app without dependencies (but with composer.json) => Build fails at Composer stage
• Simple index.php script with phpinfo() => Build successful, failed to start

Tried different options in buildpack.yml, namely webserver and libdir. Also tried without buildpack.yml at all. Always with the same result.

Full output "Laravel app without dependencies" scenario

$ pack build laravel-cloudnative -p ./laravel-cloudnative --builder gcr.io/paketo-buildpacks/builder:base --buildpack gcr.io/paketo-buildpacks/php
base: Pulling from paketo-buildpacks/builder
Digest: sha256:83c60fcd6def0a3b6f9a1cbf049345a54dd43b6603041d19d61c08c46edd7185
Status: Image is up to date for gcr.io/paketo-buildpacks/builder:base
base-cnb: Pulling from paketo-buildpacks/run
Digest: sha256:30cd86c9a265a39629421fea0172be15cd4aefb9f7f432e98a330583196f172e
Status: Image is up to date for gcr.io/paketo-buildpacks/run:base-cnb
latest: Pulling from paketo-buildpacks/php
Digest: sha256:b9f721e26071d5b216ef72154fa7b52b1821b752e83c1cac0609e7d91bd81a45
Status: Image is up to date for gcr.io/paketo-buildpacks/php:latest
0.9.1: Pulling from buildpacksio/lifecycle
Digest: sha256:53bf0e18a734e0c4071aa39b950ed8841f82936e53fb2a0df56c6aa07f9c5023
Status: Image is up to date for buildpacksio/lifecycle:0.9.1
===> DETECTING
[detector] 3 of 5 buildpacks participating
[detector] paketo-buildpacks/php-dist     0.0.208
[detector] paketo-buildpacks/php-composer 0.0.127
[detector] paketo-buildpacks/php-web      0.0.133
===> ANALYZING
[analyzer] Restoring metadata for "paketo-buildpacks/php-dist:php" from app image
[analyzer] Restoring metadata for "paketo-buildpacks/php-web:php-web" from app image
===> RESTORING
[restorer] Restoring data for "paketo-buildpacks/php-dist:php" from cache
===> BUILDING
[builder] Paketo PHP Buildpack 0.0.208
[builder]   Resolving PHP version
[builder]     Candidate version sources (in priority order):
[builder]       composer.lock    -> "^7.2.5"
[builder]       default-versions -> "7.2.*"
[builder]
[builder]     Selected PHP version (using composer.lock): 7.4.9
[builder]
[builder]   Reusing cached layer /layers/paketo-buildpacks_php-dist/php
[builder]
[builder]
[builder] Paketo PHP Composer Buildpack 0.0.127
[builder]    1.10.10: Contributing to layer
[builder]     Downloading from https://buildpacks.cloudfoundry.org/dependencies/composer/composer_1.10.10_linux_noarch_any-stack_8f16aa77.phar
[builder]     Verifying checksum
[builder]     Expanding to /layers/paketo-buildpacks_php-composer/composer
[builder]   PHP Composer Cache e57a3520f2fcb109f78c013afc32e8c9178ebda4c9b9e14a706c666172c8902a: Contributing to layer
[builder] php: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory
[builder] exit status 127
[builder] ERROR: failed to build: exit status 106
ERROR: failed to build: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 145

Environment
OS: Windows 10 Version 1909
Docker: version 19.03.12
pack: version 0.13.1+git-4134cc6.build-1135

PHP Builtin Server + FPM?

Context

The pre-restructured PHP Web buildpack which includes support for FPM and the web servers (built-in, HTTPD, Nginx) does not have support for the PHP Builtin Server + FPM together. In Restructure RFC 0001 however, the PHP FPM buildpack is present in the PHP Builtin Server order group.

There are two use cases for FPM: The first is running the FPM process on the same container as the web server (which is what PHP Start does as of release v0.1.0). The second scenario is running FPM in a separate container from the server (not implemented, but tracked in an issue)

Issue

We should investigate if there is a use case to have FPM + builtin server, and if so we should implement functionality for these two to work together.
This may involve porting the PHP builtin server buildpack over to the PHP start buildpack in order to leverage the progmgr functionality there.

Outcome

If either use case is viable (running on one container, or in two separate ones), implement the feature and document the use case.

If it is not a viable feature, we should amend the restructure RFC to remove FPM from the builtin server use case.

Upgrade to packit v2

Please upgrade to the latest packit v2 release to enable new features and extended support.

Readme should detail the supported stack/builder

See #257, it's not clear why someone can't just use the bionic base builder

Restructure buildpack: Update language family order groups

Context

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

Issue

This issue is to update the language family order groupings to make use of newly added PHP buildpacks:

• php-fpm
• php-httpd
• php-nginx
• php-builtin-server
• php-memcached-session-handler (optional = true)
• php-redis-session-handler (optional = true)

These buildpacks will be split into three order groupings, and will take the place of the php-web buildpack

This issue is blocked on issues related to the implementation each of those buildpacks:
https://github.com/paketo-buildpacks/php/issues/476
paketo-buildpacks/php-httpd#2
#479
https://github.com/paketo-buildpacks/php/issues/477
paketo-buildpacks/php-memcached-session-handler#1
paketo-buildpacks/php-redis-session-handler#1

• Add new order groups, remove PHP web
• Add new integration tests (and fixtures if needed)
• Update README accordingly

Acceptance

1. With the new language family buildpack, I can successfully:

• Build an image to run HTTPD web server with php
• Build an image to run Nginx web server with php
• Build an image to run Built-in php web server
• Build an image to run FPM1 process manager
• Build an image to run a PHP CLI script using Procfile.
• Optionally use composer as application level package manager*
• Optionally use memcached/redis as session handler

2. The order groupings in the PHP Language family buildpack look like:

[[order]] # HTTPD web server

  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/composer"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/composer-install"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/httpd"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-fpm"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-httpd"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-memcached-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-redis-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = ""
    optional = true

[[order]] # Nginx web server

  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/composer"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/composer-install"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/nginx"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-fpm"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-nginx"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-memcached-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-redis-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = ""
    optional = true

[[order]] # Built-in web server (web), FPM (php-fpm) & Script (Procfile)

  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/composer"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/composer-install"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-fpm"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-builtin-server"
    version = ""

  [[order.group]]
    id = "paketo-buildpacks/php-memcached-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/php-redis-session-handler"
    version = ""
    optional = true

  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = ""
    optional = true

Week of 2022/11/1 - PHP Buildpack releases

Add Environment Variables Buildpack to Group Order

We should consider adding the Paketo Environment Variables Buildpack to the PHP Language family buildpack so that users can define environment variables during build time to get set on the application image.

PHP Language family CNB releases should contain a buildpackage artifact

Context
As buildpackages start to become the standard of shipping our CNBs, we should build a buildpackage of our Paketo language family PHP CNB. This will make it way easier for users to consume specific language family buildpacks.

Proposal
start publishing a Paketo PHP buildpackage whenever we ship a new release artifact.

Notes/Helpful Links

• The pack command that we will have to run to do this is pack package-buildpack <NAME-OF-ARTIFACT> --package-config <Path/To/Package.toml>.

Acceptance/Deliverables

• A committed (and updated) package.toml file that can be used to re-create language family buildpackage artifacts.
• PHP Language Family CNB github releases should contain an online buildpackage artifact in the release assets.
• PHP Buildpackage can be downloaded from Github and used to pack build apps

[deleted]

Restructure buildpack: Update composer groups in language family

Context

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

Issue

This issue is to update the language family order groupings to replace php-composer with composer and composer-install.

This issue is blocked on #473. Once completed, both composer and composer-install can be added to the buildpack.toml order groupings,

Please update the README accordingly.

Acceptance

1. The order grouping in the PHP Language family buildpack looks like:

...
  [[order.group]]
    id = "paketo-buildpacks/php-dist"
    version = ...

  [[order.group]]
    id = "paketo-buildpacks/composer"
    optional = true
    version = ...

  [[order.group]]
    id = "paketo-buildpacks/composer-install
    optional = true
    version = ...
...

2. I can build a composer app such as the Paketo composer sample app with this version of the PHP language family.

Implement Paketo RFC 0038: CycloneDX + Syft SBOM

Blocked

This issue is blocked on the completion of #485

Issue

To implement Paketo RFC0038, this buildpack (and the implementation buildpacks inside) will need to move from storing SBOM information in layer metadata to storing it in files that the CNB lifecycle can manipulate during the build. The RFC outlines what these files are and what they should contain.

This issue serves as a meta-issue for work required to complete this work for the PHP language family.

• Evaluate the composition of the PHP language family and determine which buildpacks should have an SBOM associated with them.
• File issues to implement this work for each applicable implementation buildpack in the PHP language family
• Link issues to this issue

Adding support for a filesystem SBOM will now be in addition to the existing label-based SBOM and will not be a breaking change.

Add CA Certificates Buildpack to Group Ordering

We should add the CA Certificates Buildpack to each group in the buildpack. This buildpack will allow application developers to provide their own CA certificates and have them included in the root truststore at build and runtime.

Restructure buildpack: Create composer-install buildpack

Context

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

Issue

This issue is create a composer-install buildpack, but it is blocked on paketo-buildpacks/composer-install#4 and paketo-buildpacks/composer#12.

• API: The composer-install buildpack should provide none and require php and require composer at build-time.
  This buildpack should be responsible for resolving, and installing project dependencies using composer.

• Packit: This buildpack should be written using the packit library. Since this issue will come after paketo-buildpacks/composer-install#4, logic to perform dependency resolving/installation can be taken from there, and should already be written in packit.

• Buildpack API Version: This buildpack should be written using Buildpack API 0.7. Again, since this issue will come after paketo-buildpacks/composer-install#4, the API should already be 0.7 compliant.

• README: Make sure a README is added that conveys context about the buildpack in a manner consistent with other Paketo buildpacks.

This issue can be transferred to the appropriate repository (paketo-buildpacks/composer-install), once it has been created.

Acceptance

1. The buildpack provides none and requires php and requires composer
2. I can use this buildpack in conjunction with the PHP Dist buildpack and Composer buildpack to successfully build some composer app

Week of 2022/11/16 - PHP Buildpack releases

Can we support custom extensions?

Context

Issue #355 brought up the need for allowing the usage of extensions outside of the set that are shipped with the distribution of PHP. Right now, there's no way to do this unless we add a new extension to the list we include in the PHP dependency in the buildpacks. This is less than ideal because it could become a never-ending cycle of adding extensions in a one-off manner whenever someone needs one.

Issue

With paketo-community/explorations#8 on the horizon, it might be good to consider if we can find a way to allow for a more flexible set of extensions for PHP. Whether this is during the PHP compilation process, or delegated to a buildpack we should investigate how to make this possible.

Outcome

We have a separate issue that outlines a tangible way a user could use non-default extensions with their PHP app when using the PHP CNB.

Print warning when selected runtime version is/will be going EOS

Similar to the work done in the Node.js and Go Buildpacks, we should start printing deprecation messages in all PHP buildpacks that let users select a runtime version when a dependency is/will be EOS.

Release Paketo PHP Buildpack

Release in the week of May 17th if relevant changes or dependency updates are merged.

What steps did you take to close this issue? What resources did you use? How long did you spend on this task this week? Answer in a comment.

How to install PDO PHP extension in paketo PHP buildpacks

What happened?

I'm trying to build CakePHP application using paketo PHP buildpack. But I'm not sure how to install(or enable) PDO PHP extension with PHP bulidpack. It seems that there are no packages related to PDO extension in the package list here.

https://github.com/paketo-buildpacks/stacks/blob/main/packages/full/run

How can I use PDO extension with the PHP buildpack?

• What were you attempting to do?

I'm attempting to build CakePHP application using paketo PHP buildpack.

$ pack build cakephp-buildpacks-demo --buildpack gcr.io/paketo-buildpacks/php --builder paketobuildpacks/builder:full --clear-cache

• What did you expect to happen?

When I access http://localhost:8080 with a browser, it shows the CakePHP welcome page.

• What was the actual behavior? Please provide log output, if possible.

I got the following error page.

$ docker run -it --env PORT=8080 -p 8080:8080 cakephp-buildpacks-demo
2021/01/07 03:18:38 [notice] 18#0: using the "epoll" event method
2021/01/07 03:18:38 [notice] 18#0: nginx/1.19.4
2021/01/07 03:18:38 [notice] 18#0: built by gcc 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
2021/01/07 03:18:38 [notice] 18#0: OS: Linux 5.4.39-linuxkit
2021/01/07 03:18:38 [notice] 18#0: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2021/01/07 03:18:38 [notice] 18#0: start worker processes
2021/01/07 03:18:38 [notice] 18#0: start worker process 19
2021/01/07 03:18:38 [notice] 18#0: start worker process 20
[07-Jan-2021 03:18:38] NOTICE: fpm is running, pid 17
[07-Jan-2021 03:18:38] NOTICE: ready to handle connections
172.17.0.1 - - [07/Jan/2021:03:18:44 +0000] "GET / HTTP/1.1" 500 65438 vcap_request_id=-

Build Configuration

Please provide some details about your build configuration.

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.

$ pack --version
0.15.1+git-79adc30.build-1660

• What buildpacks are you using? Please include versions.

paketo-buildpacks/nginx        0.0.194
paketo-buildpacks/php-dist     0.1.0
paketo-buildpacks/php-composer 0.1.1
paketo-buildpacks/php-web      0.0.136

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

paketobuildpacks/builder:full

• Can you provide a sample app or relevant configuration (buildpack.yml,
  nginx.conf, etc.)?

$ cat buildpack.yml
---
php:
  webserver: nginx
  webdirectory: webroot

composer:
  install_options: ["--dev"]

ref: tkak/cakephp-buildpacks-demo#1

Checklist

Please confirm the following:

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Assert that builds are reproducible

Describe the Enhancement

Builds with this buildpack should be reproducible, meaning given identical inputs, the SHAs of resulting buildpack-built images are the same. This means, for a given app, if I run:

pack build my-app -b paketo-buildpacks/php

and then run

pack build my-app-copy -b paketo-buildpacks/php

with the same source code and configurations, the resulting image SHAs should be the same.

Currently, builds are not reproducible because of SBOMs included in the final app image. See paketo-buildpacks/packit#367 and paketo-buildpacks/packit#368. But once those issues are resolved and a new version of packit has been released, we should expect that the buildpack builds are reproducible.

Possible Solution

Add assertions to integration tests that show that two builds with the same inputs produce identical outputs.

Motivation

Build reproducibility is a selling point of CNBs that we want to provide to Paketo buildpack users. We want to know if future implementation decisions compromise build reproducibility.

PHP Restructure

This issue serves as an outine of the upcoming PHP restructure (per RFC 001)

Steps:

10/7 Cut PHP language family release

Support Jammy Jellyfish

Describe the Enhancement

Ultimately, we want to be able to build PHP apps on top of the Paketo Jammy stacks. Currently, builds fail because buildpacks like php-dist don't have the Jammy stack listed in their supported stacks. Since the PHP buildpack only works on the Bionic Full stack, we only expect it to be compatible with the Jammy Full stack.

Possible Solution

• Update buildpack.toml and dependencies to add io.buildpacks.stacks.jammy as a compatible stack
• (If necessary) Recompile installed dependencies to work on Jammy
• Add some integration tests that test the buildpack against Jammy

Motivation

Part of paketo-buildpacks/builder-jammy-full#1

Buildpack support for Drupal 8

I'm attempting to build Drupal 8 using PHP buildpacks. Here's a breakdown of the steps I'm doing.

1. Scaffold Drupal 8.
   composer create-project "drupal/recommended-project:^8" drupal

2. Add the following buildpack.yml.

---
php:
  version: 7.4.*
  webserver: nginx
  webdirectory: web

3. Build the container image.

pack build -b gcr.io/paketo-buildpacks/php drupal-8 --builder paketobuildpacks/builder:full

4. Run the new image.

docker run --interactive --tty --env PORT=8080 --publish 8080:8080 drupal-8

The trouble is, the build process creates a symlink of the vendor directory, and running composer install post that updates the autoload.php thus:

<?php

/**
 * @file
 * Includes the autoloader created by Composer.
 *
 * This file was generated by drupal-scaffold.
 *.
 * @see composer.json
 * @see index.php
 * @see core/install.php
 * @see core/rebuild.php
 * @see core/modules/statistics/statistics.php
 */

return require __DIR__ . '//layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/autoload.php';

Which breaks the autoload sequence.

When I edit it back to what it was,

<?php

/**
 * @file
 * Includes the autoloader created by Composer.
 *
 * This file was generated by drupal-scaffold.
 *.
 * @see composer.json
 * @see index.php
 * @see core/install.php
 * @see core/rebuild.php
 * @see core/modules/statistics/statistics.php
 */

return require __DIR__ . '/../vendor/autoload.php';

It works fine. I am not sure why we create symlinks and then run composer install again.

Copying the vendor directory instead of symlinking it would help, although there might be some rationale behind symlinking it which I'm not aware of.

Running composer install after symlinking updates the autoload.php files to reflect the new location of vendor directory.

Happy to triage any approaches/fixes and contribute back to the buildpack, and thanks for the awesome work.

Nominate Frankie G-J (@fg-j) as PHP Contributor

In accordance with the Paketo Buildpacks Governance document, I am nominating Frankie G-J (@fg-j) as a contributor to the PHP language family.

Frankie has made several important contributions to the PHP family of buildpacks - 958d0fa, paketo-buildpacks/php-dist@cdd775d, paketo-buildpacks/nginx@c29fae0 to list a few. Frankie also comes with experience contributing to Cloud Foundry Buildpacks.

Implement PHP RFC 0001: PHP Start

Per #503 and the associated RFC , we should implement the PHP Start buildpack as a part of the PHP Rewrite.

This is a placeholder issuer for implementing the PHP Start buildpack, until the RFC is merged and the API is solidified.

Cases to support:

• HTTPD + FPM in one container
• Nginx + FPM in one container
• Later on: Nginx as a proxy for FPM in a separate container (associated with paketo-buildpacks/php-fpm/issues/8)
• Later on: HTTPD as a proxy for FPM in a separate container (associated with paketo-buildpacks/php-fpm/issues/8)

How to Add PHP Extension and documentation suggestion

Hello, I would like to know how to add new PHP extensions, such as Phalcon, Swoole or some other extension not included in Buildpack?

I would also like to suggest more details like the PHP versions supported in the documentation, I was able to see it in Releases and which extensions are included natively, I missed the documentation of these details and also examples of more complete uses such as adding a new extension, adding SSL through Let's Encrypt and Database like MySQL / Mariadb and the like.

The idealization of this project is very good, if it gets a little more complete, the documentation should make it even easier to use, thanks.

PHP 8.1 support?

failed to satisfy "php" dependency version constraint "^8.1": no compatible versions on "io.buildpacks.stacks.bionic" stack. Supported versions are: [7.4.27, 7.4.28, 8.0.15, 8.0.16]

What determines which PHP versions are available? How can a new version be added?

PHP Restructure: RFC to Migrate from Buildpack.yml to Environment Variables

Context

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.

Issue

As a part of the process of bring the PHP buildpacks up to speed with other Paketo buildpacks, we should migrate from setting configurations via a buildpack.yml to using environment variables across all buildpacks, as we have already done in a number of other buildpacks.

Currently, the buildpack.yml file is used to specify:

• PHP versions,
• a user's choice of web-server,
• an alternative web app code directory to htdocs,
• alternative library code directory to lib,
• scripts,
• server admin,
• redis session store service,
• memcache session store service, and
• configuring composer

If we are moving away from the buildpack.yml pattern, alternatives for all of these options should be explained in the RFC. The README of the PHP Web buildpack contains examples of all of these fields.

Acceptance

This issue can be closed out when an RFC is added to the PHP RFCs directory

Buildpack support for Laravel 8

Hello, I'm trying to build Llaravel 8 with php buildpacks. Here is the step.

1. Create Laravel 8 project

composer create-project --no-cache --prefer-dist "laravel/laravel:8.0" laravel

2. Add the following buildpack.yml

---
composer:
  vendor_directory: vendor
php:
  version: 7.4.*
  webdirectory: public

3. Build the container image

pack build --clear-cache -b gcr.io/paketo-buildpacks/php laravel-8 --builder paketobuildpacks/builder:full

4. Run the new image

docker run --interactive --tty --env PORT=8080 --publish 8080:8080 laravel-8

Here is the log when I acess localhsot:8080

[Sat Apr 24 04:25:07 2021] 172.17.0.1:60712 [500]: GET / - Uncaught ReflectionException: Class App\Http\Kernel does not exist in /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/laravel/framework/src/Illuminate/Container/Container.php:833
Stack trace:
#0 /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/laravel/framework/src/Illuminate/Container/Container.php(833): ReflectionClass->__construct('App\\Http\\Kernel')
#1 /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/laravel/framework/src/Illuminate/Container/Container.php(714): Illuminate\Container\Container->build('App\\Http\\Kernel')
#2 /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(841): Illuminate\Container\Container->resolve('App\\Http\\Kernel', Array, false)
#3 /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/laravel/framework/src/Illuminate/Container/Container.php(284): Illuminate\Foundation\Application->resolve('App\\Http\\Kernel', Array, false)
#4 /layers/ in /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 835
[Sat Apr 24 04:25:07 2021] 172.17.0.1:60712 Closing

If my understanding is correct this problem is caused by creating a symlink of the vendor directory during the build process and ends up with autoloading failure. It would be great if you can look into this.

cnb@39425bd1d4ab:/workspace$ ll
total 352
drwxr-xr-x 12 cnb  cnb    4096 Jan  1  1980 ./
drwxr-xr-x  1 root root   4096 Apr 24 04:25 ../
-rw-r--r--  1 cnb  cnb     220 Jan  1  1980 .editorconfig
-rw-r--r--  1 cnb  cnb     829 Jan  1  1980 .env
-rw-r--r--  1 cnb  cnb     778 Jan  1  1980 .env.example
-rw-r--r--  1 cnb  cnb     111 Jan  1  1980 .gitattributes
-rw-r--r--  1 cnb  cnb     163 Jan  1  1980 .gitignore
drwxr-xr-x  2 cnb  cnb    4096 Jan  1  1980 .php.ini.d/
-rw-r--r--  1 cnb  cnb     174 Jan  1  1980 .styleci.yml
-rw-r--r--  1 cnb  cnb    3738 Jan  1  1980 README.md
drwxr-xr-x  7 cnb  cnb    4096 Jan  1  1980 app/
-rwxr-xr-x  1 cnb  cnb    1686 Jan  1  1980 artisan*
drwxr-xr-x  3 cnb  cnb    4096 Jan  1  1980 bootstrap/
-rw-r--r--  1 cnb  cnb      86 Jan  1  1980 buildpack.yml
-rw-r--r--  1 cnb  cnb    1608 Jan  1  1980 composer.json
-rw-r--r--  1 cnb  cnb  246768 Jan  1  1980 composer.lock
drwxr-xr-x  2 cnb  cnb    4096 Jan  1  1980 config/
drwxr-xr-x  5 cnb  cnb    4096 Jan  1  1980 database/
-rw-r--r--  1 cnb  cnb     974 Jan  1  1980 package.json
-rw-r--r--  1 cnb  cnb    1202 Jan  1  1980 phpunit.xml
drwxr-xr-x  2 cnb  cnb    4096 Jan  1  1980 public/
drwxr-xr-x  6 cnb  cnb    4096 Jan  1  1980 resources/
drwxr-xr-x  2 cnb  cnb    4096 Jan  1  1980 routes/
-rw-r--r--  1 cnb  cnb     563 Jan  1  1980 server.php
drwxr-xr-x  5 cnb  cnb    4096 Jan  1  1980 storage/
drwxr-xr-x  4 cnb  cnb    4096 Jan  1  1980 tests/
lrwxrwxrwx  1 cnb  cnb      67 Jan  1  1980 vendor -> /layers/paketo-buildpacks_php-composer/php-composer-packages/vendor/
-rw-r--r--  1 cnb  cnb     559 Jan  1  1980 webpack.mix.js

Pecl extensions?

I'd like to enable some PHP extensions. Some are distributed with core php (such as intl) but others are only available to install using pecl (for instance grpc).

I was unable to find any configuration related to extensions. Is this supported? If not is it planned?

Buildpack support for Symfony apps

Would it be possible to add a buildpack specifically for Symfony apps?
It would be depending on the composer buildpack if I understand how Symfony works correctly.

Implement RFC0032: Reloadable Process Types

RFC

Summary

Any relevant Paketo buildpacks should provide support to allow process reloading in the container.

Buildpacks to implement

• php-start

PHP Buildpack starting 1.2.0 is not compatible with api 0.7

buildpack.toml of the PHP Buildpack is referencing api 0.7 but two underlying buildpacks (httpd and nginx) are referencing api 0.8, thus the PHP Buildpack cannot run on a platform supporting only api 0.7.

Expected Behavior

buildpack.toml should reference an api version consistent with the platform which is required to run it.

Current Behavior

PHP buildpack starting 1.2.0 cannot run on a platform limited to api 0.7 even if its buildpack.toml is referencing api 0.7

Possible Solution

Update buildpack.toml to api 0.8

Steps to Reproduce

Try to build an image with PHP Buildpack 1.2.0 or 1.3.0 on a platform not supporting api 0.8. In my case it is Tanzu Build Service 1.5.2 which is shipped with kpack 0.5.4

Motivations

I'm repackaging the PHP Buildpack to add Oracle support. I was relying on the buildpack.toml to assure api compatibility with the platform whenever there is a new release of the buildpack on Github.

Week of 2022/10/19 - PHP Buildpack releases

Add Image Labels Buildpack to Group Order

We should add the Image Labels Paketo Buildpack to the group order so that the PHP Paketo Buildpack conforms to the image labels RFC