Automatic builds to incorporate upstream security fixes?

[jasonhildebrand]

Description

Thanks for your work in this project. I am aware that these are not production-ready images, and are not advertised as such. And that's fine. I use your images as base images for my development & production images, and believe it absolutely makes sense to use the same base images across dev/staging/production to minimize differences between these environments.

My question is whether you'd be open to building images more frequently (ideally automatically) in order to pick up upstream security fixes. For example, when PHP releases security updates, it would be nice to see freshly built images like markoshust/magento-php:8.2-fpm-4 as well as markoshust/magento-php:8.2.26-fpm-4 (this last one does not currently exist, but it's what I would hope to see).

If these rebuilds could be automated via github actions, would you be open to accepting a PR? I'd envision a daily job which checks for new upstream PHP images, and rebuilds if there is a new version, applying an appropriate tag.

I understand if this is not a direction you want to go, that's why I'm asking. It's important for me (and I presume many other users) to know what to expect and how to plan to push out security updates.

[rubenromao]

Hi @jasonhildebrand, interesting, I didn't even know that was possible.
@markshust any thoughts about this proposal, please?

[markshust]

I like this idea, but I'm not sure it it's needed, especially with Magento's fairly slow release cycle. There are also some updates that I purposely hold back because they either don't work, or are incompatible with Magento's system requirements (for example, pegging Composer at version 2.7, and not a more recent version, because 2.8 is not "officially" supported).

That said, I think the builds can definitely be streamlined, which would make the update process much less painful for me, which would lead to more frequent releases. For example, there will now be 4 actively-maintained PHP versions (8.1 through 8.4), and they all share a very common setup, with slightly different versions for their unique case.

In this scenario, something like multi-stage builds could lead this to a standard "base" PHP Dockerfile, and then each version can have their specific overrides. I know how to do this and would like to do it ASAP, but it's been a while since a release happened (ironically 🙃), so I'm going to push that release out first before implementing this. Additionally, I need to manually update the versions of each Dockerfile in the current GitHub Action files, for example, updating the specific tag for each new version. There is also a lot of redundancy in the build files, and I'm sure they can be streamlined.

So, I'd say that I'd probably avoid going down the auto-build rabbit hole right now, but there are many areas of improvement that can greatly simplify this setup first and are much lower-hanging fruit. They may also make auto-updates much more feasible in the future.

I'll leave this ticket open a bit so we can discuss and see where this goes.

[jasonhildebrand]

Thanks for your thoughts, Mark.

I'll just provide a concrete example of why this would be helpful. PHP released 8.2.26 a few days ago, which includes several security fixes. Magento already supports 8.2, so this is not a case where we can't yet use this version. Production sites (or publically accessible staging sites) currently running 8.2.x should be updated to this version, sooner rather than later.

My options (as someone who uses your magento-php image as my base image) are

• wait for you to push out a new release
• work around this by updating my Dockerfile to base it on upstream (php:8.2-fpm-bookworm), and copy all your Dockerfile rules into the top of mine. The downside is that I lose out on future improvements you make, and my builds take much longer.

I don't want to pressure you with need to manually push out a new release any time this happens. That's why I suggested an automated solution.

I think it is possible to parameterize the base image (e.g. using 8.2.26-fpm-bookwork instead of 8.2-fpm-bookworm) used in your Dockerfiles, so you'd still have just four PHP dockerfiles to maintain, not hundreds. But ideally the released images would be tagged with the minor version numbers (8.2.26, not just 8.2).

[markshust]

Thanks for your follow-up. I think if we keep this at the service-level (PHP, MySQL, etc.) and not the package level (specific versions of imagick, xdebug, etc.), this would probably work, so long as we could build an automatic solution to this with some kind of GitHub Action workflow.

[andkirby]

@jasonhildebrand this is why I prefer to build images locally instead pulling pre-built ones.

And as a workaround, instead of just pulling Mark's images, you may pull files from /images directory and re-build your images locally.

And I'd say this is a must-have approach for projects, as you need to build an image with the exact version for the whole dev team and all instances. E.g. for PHP-FPM, it can be 8.4.1.