Hi Internals.
PHP currently does not provide official container images. Given that
DockerHub adequately maintains these and considering the maintenance costs,
we haven't felt the need to change the status quo.
However, the official DockerHub images lack debug builds, which can be
somewhat inconvenient when trying to report bugs or reproduce issues.
What if we were to provide debug build container images that are compatible
with the official DockerHub images? Fortunately, we already conduct most of
our development on GitHub, which has a container registry called Packages.
This could be achieved simply by creating a single repository under the php
organization on GitHub. What are your thoughts on this?
Best Regards.
Go Kudo
+1 on this, this is very much needed, I encountered the need of a debug
version of the docker-library php image almost every week ever since
I've started recently, and recently even more, as I've been getting many
more segfault reports from my users ever since the release of 8.3.11.
Regards,
Daniil Gentili.
Hi Internals.
PHP currently does not provide official container images. Given that
DockerHub adequately maintains these and considering the maintenance
costs, we haven't felt the need to change the status quo.However, the official DockerHub images lack debug builds, which can be
somewhat inconvenient when trying to report bugs or reproduce issues.What if we were to provide debug build container images that are
compatible with the official DockerHub images? Fortunately, we already
conduct most of our development on GitHub, which has a container
registry called Packages.This could be achieved simply by creating a single repository under
the php organization on GitHub. What are your thoughts on this?Best Regards.
Go Kudo
This would help the FrankenPHP project a lot!
The build script used for the official images already contains an
environment variable for creating variants containing debugging symbols:
https://github.com/docker-library/php/blob/a15b1e1448d2f99db63f68dc4ce21da9a82f5aad/Dockerfile-linux.template#L406
Basically, all the PHP project has to do is build and publish these debug
images. I can help with that.
Best,
On Mon, Sep 2, 2024 at 4:40 PM Daniil Gentili daniil.gentili@gmail.com
wrote:
+1 on this, this is very much needed, I encountered the need of a debug
version of the docker-library php image almost every week ever since
I've started recently, and recently even more, as I've been getting many
more segfault reports from my users ever since the release of 8.3.11.Regards,
Daniil Gentili.
Hi Internals.
PHP currently does not provide official container images. Given that
DockerHub adequately maintains these and considering the maintenance
costs, we haven't felt the need to change the status quo.However, the official DockerHub images lack debug builds, which can be
somewhat inconvenient when trying to report bugs or reproduce issues.What if we were to provide debug build container images that are
compatible with the official DockerHub images? Fortunately, we already
conduct most of our development on GitHub, which has a container
registry called Packages.This could be achieved simply by creating a single repository under
the php organization on GitHub. What are your thoughts on this?Best Regards.
Go Kudo
Hi Internals.
PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo.
However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues.
What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages.
This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this?
Best Regards.
Go Kudo
Since the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds.
Perhaps there’s someone from that team on this list who can speak to that?
Cheers,
Ben
Hi Internals.
PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo.
However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues.
What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages.
This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this?
Best Regards.
Go KudoSince the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds.
Perhaps there’s someone from that team on this list who can speak to that?
Cheers,
Ben
Hey Ben,
what I'd really like to see is not debug-builds, but debug symbols.
Basically, you'd have a docker image "php:8.3" and a docker image
"php:8.3-dbgsym". The former image then just has a gnu_debuglink. The
latter has the actual symbols file included and is based on the former.
Thanks,
Bob
Hi Internals.
PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo.
However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues.
What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages.
This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this?
Best Regards.
Go KudoSince the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds.
Perhaps there’s someone from that team on this list who can speak to that?
Cheers,
BenHey Ben,
what I'd really like to see is not debug-builds, but debug symbols.
Basically, you'd have a docker image "php:8.3" and a docker image "php:8.3-dbgsym". The former image then just has a gnu_debuglink. The latter has the actual symbols file included and is based on the former.
Thanks,
Bob
I think the team who manages the Docker builds could also provide images with debug symbols. Since they’re already equipped for it and have the experience, why don’t we partner with them to provide these images to the community?
Cheers,
Ben
Cheers,
Ben
Hi Internals.
PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo.
However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues.
What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages.
This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this?
Best Regards.
Go Kudo
Since the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds.Perhaps there’s someone from that team on this list who can speak to that?
Cheers,
Ben
Hey Ben,what I'd really like to see is not debug-builds, but debug symbols.
Basically, you'd have a docker image "php:8.3" and a docker image "php:8.3-dbgsym". The former image then just has a gnu_debuglink. The latter has the actual symbols file included and is based on the former.
Thanks,
Bob
I think the team who manages the Docker builds could also provide images with debug symbols. Since they’re already equipped for it and have the experience, why don’t we partner with them to provide these images to the community?
Cheers,
Ben
Yes. Absolutely.
The problem, however, if you want to provide a build with debug symbols
and one without, the primary value for me would be being able to take a
core dump produced in an image without debug symbols and then simply
open the image with debug symbols and inspect it there.
To the best of my knowledge however, it isn't trivially possible to
build two docker images with the same docker build invocation. Basically
you'd need an intermediary image, from which you then create both (so, 3
different docker builds - one base image which has the build and the
symbols but is not uploaded. And two images where the base images files
are copied into.). I believe this would not be compatible with the way
docker-library/php is built currently.
So, yes, please reach out to them what they are willing to do.
Thanks,
Bob
Hi Internals.
PHP currently does not provide official container images. Given that DockerHub adequately maintains these and considering the maintenance costs, we haven't felt the need to change the status quo.
However, the official DockerHub images lack debug builds, which can be somewhat inconvenient when trying to report bugs or reproduce issues.
What if we were to provide debug build container images that are compatible with the official DockerHub images? Fortunately, we already conduct most of our development on GitHub, which has a container registry called Packages.
This could be achieved simply by creating a single repository under the php organization on GitHub. What are your thoughts on this?
Best Regards.
Go KudoSince the folks who do the DockerHub builds already have all the infrastructure set up to maintain the images, I think it might be easier to work with them to have them provide debug builds.
Perhaps there’s someone from that team on this list who can speak to that?
Cheers,
BenHey Ben,
what I'd really like to see is not debug-builds, but debug symbols.
Basically, you'd have a docker image "php:8.3" and a docker image "php:8.3-dbgsym". The former image then just has a gnu_debuglink. The latter has the actual symbols file included and is based on the former.
Thanks,
Bob
I think the team who manages the Docker builds could also provide images with debug symbols. Since they’re already equipped for it and have the experience, why don’t we partner with them to provide these images to the community?
Cheers,
Ben
Yes. Absolutely.
The problem, however, if you want to provide a build with debug symbols and one without, the primary value for me would be being able to take a core dump produced in an image without debug symbols and then simply open the image with debug symbols and inspect it there.
To the best of my knowledge however, it isn't trivially possible to build two docker images with the same docker build invocation. Basically you'd need an intermediary image, from which you then create both (so, 3 different docker builds - one base image which has the build and the symbols but is not uploaded. And two images where the base images files are copied into.). I believe this would not be compatible with the way docker-library/php is built currently.
So, yes, please reach out to them what they are willing to do.Thanks,
Bob
I opened an issue on their GitHub tracker to gauge their interest: https://github.com/docker-library/php/issues/1538
Cheers,
Ben
2024年9月3日(火) 10:35 Ben Ramsey ramsey@php.net:
Hi Internals.
PHP currently does not provide official container images. Given that
DockerHub adequately maintains these and considering the maintenance costs,
we haven't felt the need to change the status quo.However, the official DockerHub images lack debug builds, which can
be somewhat inconvenient when trying to report bugs or reproduce issues.What if we were to provide debug build container images that are
compatible with the official DockerHub images? Fortunately, we already
conduct most of our development on GitHub, which has a container registry
called Packages.This could be achieved simply by creating a single repository under
the php organization on GitHub. What are your thoughts on this?Best Regards.
Go KudoSince the folks who do the DockerHub builds already have all the
infrastructure set up to maintain the images, I think it might be easier to
work with them to have them provide debug builds.Perhaps there’s someone from that team on this list who can speak to
that?Cheers,
BenHey Ben,
what I'd really like to see is not debug-builds, but debug symbols.
Basically, you'd have a docker image "php:8.3" and a docker image
"php:8.3-dbgsym". The former image then just has a gnu_debuglink. The
latter has the actual symbols file included and is based on the former.Thanks,
Bob
I think the team who manages the Docker builds could also provide
images with debug symbols. Since they’re already equipped for it and have
the experience, why don’t we partner with them to provide these images to
the community?Cheers,
Ben
Yes. Absolutely.
The problem, however, if you want to provide a build with debug symbols
and one without, the primary value for me would be being able to take a
core dump produced in an image without debug symbols and then simply open
the image with debug symbols and inspect it there.
To the best of my knowledge however, it isn't trivially possible to
build two docker images with the same docker build invocation. Basically
you'd need an intermediary image, from which you then create both (so, 3
different docker builds - one base image which has the build and the
symbols but is not uploaded. And two images where the base images files are
copied into.). I believe this would not be compatible with the way
docker-library/php is built currently.
So, yes, please reach out to them what they are willing to do.Thanks,
BobI opened an issue on their GitHub tracker to gauge their interest:
https://github.com/docker-library/php/issues/1538Cheers,
Ben
Hi.
I think it's great that drop-in replacement images are being provided on
DockerHub. Thank you for the suggestion!
However, I believe it would be beneficial to have image variants as well.
For instance, providing images with LLVM MemorySanitizer enabled builds
would allow us to easily conduct various tests using our local PHP code.
This would also be useful for testing third-party extensions.
For safely developing PHP extensions, I primarily use the following build
variants:
- The build provided by DockerHub
- GCC debug build
- GCC debug with gcov build
- GCC Valgrind build
- Clang MSan build
- Clang ASan build
- Clang UBSan build
These images are intended for development purposes, and it might be
challenging to host them on DockerHub, which typically hosts images for
general use. That said, I already maintain these [1], and I think it could
be beneficial to offer them as official PHP images. Of course, I plan to
continue maintaining them if we decide to do so.
Additionally, I'd like to point out that we could utilize the existing
GitHub infrastructure for both the build environment and hosting
environment when publishing these images.
[1] https://github.com/colopl/pskel
Best Regards,
Go Kudo
It seems like the discussion on github has stalled...
2024年9月15日(日) 0:15 Daniil Gentili daniil.gentili@gmail.com:
It seems like the discussion on github has stalled...
Hello,
I've been continuing to approach this issue and I'm considering whether we
could publish nightly builds of php-src as container images on GitHub
Packages.
If this becomes a reality, it would allow for quicker reproduction of bugs
and setup of development environments.
https://github.com/zeriyoshi/php-containers-development/pkgs/container/php-containers-development
I feel we could meet the requirements if we could create an image based on
this one that's compatible with the php image on DockerHub.
Best regards,
Go Kudo