Build and release low-size images with binary only

[Wirone]

Fixes #249

ℹ️ INFO

I think it can be cleaned up to minimise redundancy, but I did not want refactor current process, rather follow existing convention. Dockerfiles are fully backward compatible, because the last target in the file (which is built when --target option is not defined) builds full image, same as currently.

dive output for standalone-binary and binary-with-runtime target builds:

2.4MB vs 188MB, quite a difference 😉

❓ Questions / doubts:

• Should I add some info to the Readme?
• As far as I understand PRs to official Docker library are created manually? Because I did not found it here. Will it be straightforward to add *-bin images there from now on?
• can we test it by tagging some RC version?

[Wirone]

This looks good to me. It might be interesting in future to build them together with bake

@ciaranmcnulty do you mean docker buildx bake? I've never used it unfortunately, but seems like interesting idea. I rather thought about making some Github Actions matrix, so some logic could be extracted and parameterised. But I went with "good enough" approach for now 😉

Let's see what @alcohol says about it 🙂

[alcohol]

I think a binary-only image is a good idea. The current build process/matrix is a bit crude admittedly, but, it works (:tm:) :sweat_smile: . Probably due for an overhaul, but this PR might do for now. Though it does not account for how the official images are generated. So in its current state, it would only apply for the community image on Docker Hub and Amazon ECR.

[Wirone]

Though it does not account for how the official images are generated. So in its current state, it would only apply for the community image on Docker Hub and Amazon ECR.

Yes, I know and it was done like this on purpose. There's a doubt in PR's description:

As far as I understand PRs to official Docker library are created manually? Because I did not found it here. Will it be straightforward to add *-bin images there from now on?

I just thought I will follow this repository's convention and official tags will be handled somewhere else 😉 Even with regular composer/composer community image it would allow better builds using COPY --from (especially when you consider manual work required to update official registry and time overhead to make it available for download).

I think it could be solved in separate MR that could automate process of creating MRs to official Docker registry. Anyway, not a blocker IMHO.

[alcohol]

I think it could be solved in separate MR that could automate process of creating MRs to official Docker registry. Anyway, not a blocker IMHO.

This is probably doable. It actually is not very complicated. I update my fork of docker-library/official-images using the generate-stackbrew-library.sh script from this repository. I redirect the output of said script to library/composer, commit and push my changes, and then submit a pull-request (which takes like 2 seconds using gh create pr from CLI). This script is also what needs to be modified if we want to submit the binary tags to the official-images repository. I think it is partially based on directory structure. I have never really dived into the inner workings of it in great detail; only enough to properly setup the alias for latest and shortened versions (1, 2, etc).

[alcohol]

Sorry for taking so long to get back to this. Could you update your PR to take into account the 2.4 directory? I'll merge it ASAP then.

[Wirone]

@alcohol Done 🙂 Great news!

PS. I did not remove you from review, I just clicked "request re-review" from @ciaranmcnulty 🤷‍♂️

[alcohol]

Cheers

[alcohol]

Drats, this change seems to have broken the bashbrew script. Can't quite figure out what step though.

[Wirone]

@alcohol can you point me to that "bashbrew script"? What's failing?

[alcohol]

I managed to patch it. Turns out it wasn't really setup to parse dockerfiles with multiple FROM sources.