2024年9月3日(火) 10:35 Ben Ramsey <ram...@php.net>:

> > On Sep 2, 2024, at 19:36, Bob Weinand <bobw...@hotmail.com> wrote:
> >
> > On 3.9.2024 02:18:30, Ben Ramsey wrote:
> >>> On Sep 2, 2024, at 18:53, Bob Weinand <bobw...@hotmail.com> wrote:
> >>>
> >>> On 3.9.2024 01:44:21, Ben Ramsey wrote:
> >>>
> >>>>> On Sep 2, 2024, at 08:11, Go Kudo <zeriyo...@gmail.com> wrote:
> >>>>>
> >>>>> 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
>
>
> I opened an issue on their GitHub tracker to gauge their interest:
> https://github.com/docker-library/php/issues/1538
>
> Cheers,
> 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

Reply via email to