Current main-branch version of buildpack isn't deployable

[arthfl]

Ahoy,

The current main branch (7b37993) seems to have a bug that lets a very simple app deployment fail currently:

2025-12-16T10:14:02.29+0100 [STG/0] OUT -----> Finalizing PHP
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Copied rewrite binary to .bp/bin
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Loading default options from embedded config
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Set PHP_DEFAULT = 8.1.32 from manifest
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Set PHP_81_LATEST = 8.1.32
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Set PHP_82_LATEST = 8.2.28
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Set PHP_83_LATEST = 8.3.21
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Using web server: httpd (from options.json)
   2025-12-16T10:14:02.29+0100 [STG/0] OUT Created start script for httpd
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Created pre-start wrapper script
   2025-12-16T10:14:02.29+0100 [STG/0] OUT DEBUG: Created PHP runtime directory: /tmp/contents667600700/deps/0/php/var/run
   2025-12-16T10:14:02.29+0100 [STG/0] OUT PHP buildpack finalize phase complete
   2025-12-16T10:14:05.17+0100 [STG/0] ERR Failed to build droplet release: buildpack's release output invalid: yaml: line 4: mapping values are not allowed in this context
   2025-12-16T10:14:05.18+0100 [STG/0] OUT Exit status 224
   2025-12-16T10:14:05.69+0100 [STG/0] OUT Cell c2ce894c-7146-4119-8f66-065da745909f stopping instance e2f5e0b4-9f57-4b0c-b9a1-84a86c076b35
   2025-12-16T10:14:05.69+0100 [STG/0] OUT Cell c2ce894c-7146-4119-8f66-065da745909f destroying container for instance e2f5e0b4-9f57-4b0c-b9a1-84a86c076b35
   2025-12-16T10:14:05.75+0100 [API/0] ERR Failed to stage build: staging failed

This is from a minimal hello-world-ish sample app we deploy daily to test our (Dynatrace) buildpack integration.
The manifest looks like

---
applications:
  - name: php-sample
    memory: 256M
    instances: 1
    buildpacks:
        - https://github.com/cloudfoundry/php-buildpack.git
    env:
      BP_DEBUG: true

This is happening since November 21st 2025 constantly.

The latest stable release of the php-buildpack works just fine.

[ramonskie]

i am sorry it took so long for me to repsond
but i found the bug.
it was related to setting the

    buildpacks:
        - https://github.com/cloudfoundry/php-buildpack.git

which caused yml polution that we where not handling properly
when we refactored this buildpack to go libbuildpack.

[ramonskie]

it should now be fixed within 9fad270

[meibensteiner]

@ramonskie When is 5.0.2 going out? If I'm not mistaken the buildpack is still broken.
These buildpacks are used by large companies who count on our reliability and should they update they will have no observability at all.

[ramonskie]

i just release 5.0.2
but keep in mind that it only failed if users where setting the buildpack url. within there app manifest

so it would work if it was a deployed with bosh release https://github.com/cloudfoundry/php-buildpack-release

de bosh-release zal later deze week of begin volgende week gebeuren

[arthfl]

@ramonskie
It failed when referencing the buildpack via URL because the content in the main branch was/is broken. From my understanding of dealing with buildpacks in the past 8 years, the main branch was supposed to be rather stable and is what the releases are based on.
I don't see what difference it will make how a buildpack is fetched during the app staging process. If the content is broken, it's broken.

So i guess this is not supposed to be fixed already since this issue has beeen re-opened?

[ramonskie]

it is fixed.
i closed it by accident so i reopend it. because i wanted to give you to opportunity to close it if our latest changes fixed your problem.

the difference is pretty notable.
as not allot of ppl use the latest pull from master for there application.
but rather use a versioned buildpack either by bosh release or pushed in to cloudfoundry

and yes master is rather stable but rather stable does not mean without bugs.

but it seemed you are rather pissed.
i made allot of effort to refactor the php buildpack so it would receive better and more update support.
as the php-buildpack is a bit of a forgotten child that did not receive allot of attention.

[arthfl]

it is fixed.

It is not:
2026-01-22T10:19:36.08+0100 [APP/PROC/WEB/0] ERR /home/vcap/app/.bp/bin/rewrite: line 7: /home/vcap/app/.bp/scripts/install_go.sh: No such file or directory

This was with a simple manifest that used the main branch:

---
applications:
  - name: php-apache-test
    memory: 256M
    instances: 1
    buildpacks:
      - https://github.com/cloudfoundry/php-buildpack.git
    env:
      BP_DEBUG: true

[ramonskie]

i commited a fix.
its currently going trough our pipelines.
but you should be able to test again now. and let me know the results

[arthfl]

Just deployed, referencing main. The same error persists:

2026-01-23T11:05:16.35+0100 [APP/PROC/WEB/0] ERR /home/vcap/app/.bp/bin/rewrite: line 7: /home/vcap/app/.bp/scripts/install_go.sh: No such file or directory

[ramonskie]

i am sorry. i noticed that our whole testing suite has been messed up and i thought it was actually testing several scenarrios. but it was commented out for debugging purposes..

this is why we never caught these errors.

i currently stumbled on a design flaw. that needs a whole new approach.
that is related to the rewrite tool that was used in the old buildpack.

this will take some time.
im even thinking of yanking the old 5.x version as they are currently in a semi broken state.

[meibensteiner]

I would recommend yanking the 5.x versions released so far. As far as I understood there is no chance a customer would be able to use them. Save yourself the Support Requests.

[ramonskie]

i made a pr #1218

could you try that branch with

---
applications:
  - name: php-apache-test
    memory: 256M
    instances: 1
    buildpacks:
      - https://github.com/cloudfoundry/php-buildpack.git#remove-rewrite-binary-clean
    env:
      BP_DEBUG: true

[akf]

Hi, I found this thread while trying to figure out why a build started failing. The platform I'm deploying to recently started supplying version 5.0.1 by default. I'm seeing some different errors, and I thought I'd share them for your awareness. I have re-tested with the remove-rewrite-binary-clean and I still see some issues.

Unfortunately there's a lot going on with this app and I usually don't debug buildpacks, I just specify them and cf push. In addition to the specific configuration options I note below, this app uses the apt_buildpack in addition to php_buildpack. But the first item here is easy to reproduce with a minimal app.

1. We set "PHP_VERSION": "{PHP_83_LATEST}" in .bp-config/options.json. The build fails with:

   DEBUG: Updated PHP version from extension context: {PHP_83_LATEST}
   Installing PHP {PHP_83_LATEST}
   -----> Installing php {PHP_83_LATEST}
   **ERROR** DEPENDENCY MISSING IN MANIFEST:
   
   Version {PHP_83_LATEST} of dependency php is not supported by this buildpack.
   The versions of php supported in this buildpack are:
   - 8.1.32
   - 8.1.34
   - 8.2.28
   - 8.2.29
   - 8.3.21
   - 8.3.30

Earlier in the same log I see this, by the way:

   DEBUG: Set PHP_83_LATEST = 8.3.30

2. Using the remove-rewrite-binary-clean branch and hard-coding version to 8.3.21 (which is what we had been getting as latest), the deployed app fails health check. I see this error message in the logs:

   2026-02-06T15:37:09.09-0800 [APP/PROC/WEB/0] ERR AH00526: Syntax error on line 9 of /home/vcap/app/httpd/conf/httpd.conf:
   2026-02-06T15:37:09.09-0800 [APP/PROC/WEB/0] ERR DocumentRoot '/home/vcap/app/#{WEBDIR}' is not a directory, or is not readable

This may have a common cause with (1), in that variables defined in .bp-config/options.json aren't being handled properly. We have .bp-config/httpd/httpd.conf with DocumentRoot "${HOME}/#{WEBDIR}" and .bp-config/options.json sets "WEBDIR": "web" (I don't know why it was set up that way).

3. With the 5.0.1 buildpack and php pinned to 8.3.21 (that is, not using the PHP_83_LATEST variable), we don't have problem (2), but once the app is up and post-install scripts that run php fail with messages indicating some kind of problem with extensions, for example:

PHP Warning:  PHP Startup: Unable to load dynamic library 'bz2.so' (tried: /tmp/app/php/lib/php/extensions/no-debug-non-zts-20230831/bz2.so (/tmp/app/php/lib/php/extensions/no-debug-non-zts-20230831/bz2.so: cannot open shared object file: No such file or directory), /tmp/app/php/lib/php/extensions/no-debug-non-zts-20230831/bz2.so.so (/tmp/app/php/lib/php/extensions/no-debug-non-zts-20230831/bz2.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0