Use docker buildx for ftl-build containers

[DL6ER]

What does this implement/fix?

This is a complete rewrite of how the ftl-build containers are built. Instead of fine-tuned, hand-crafted and with intense care written individual docker files for every target architecture (that were always creating hours of work when the distro was upgraded), we switch to docker buildx with one simple Dockerfile used for everything. This makes maintenance a lot easier and greatly simplifies the overall process.

Furthermore, this resolves one particular issue we have had a few times in the past with the dependence on particular glibc versions by switching everything to musl-based so FTL will from now on ship as fully static batteries-included binaries that can run on the irrespective of the operating system version.

This PR removes support for armv4 (last supporting Debian release was Stretch) and armv5 as these architectures are not supported by Alpine. I tried to create an armv5 binary using debian:stretch and :bullseye as base image but it - to my surprise - created an armv6 binary we cannot use.

Update: We will still generate armv4T and armv5TE binaries using Debian builders. The dependency on a sufficiently recent GLIBC remains.

The resulting containers should be tagged v2.0

Related issue or feature (if applicable): N/A

Pull request in docs with documentation (if applicable): N/A

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories developmental branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.

[DL6ER]

I left the removal of the Debian-based image intentionally in the git history. Just in case we decide to revisit Debian-based builds at some point.

[DL6ER]

@PromoFaux Alongside this change the FTL binary names change to

• pihole-FTL-amd64
• pihole-FTL-386
• pihole-FTL-armv6
• pihole-FTL-armv7
• pihole-FTL-arm64
• pihole-FTL-riscv64

Not sure if this needs some modifications in the v6 docker container?

[crazy-max]

This will checkout sources for every platform you're building which is not optimal. You can just checkout against the build platform in a dedicated stage and mount the sources here. And for cache optim you should also init and checkout instead of cloning like: https://github.com/crazy-max/docker-fail2ban/blob/c779f371005948587ed90fcc28cfd819033a8083/Dockerfile#L6-L11

[yubiuser]

You removed the pull_request trigger in ftl-build.yml (L3-6) so there is no need to check for that trigger anymore.

[PromoFaux]

Should the debian ones not be linux/arm/v4 and linux/arm/v5? Seems we have linux/arm/v6 twice...

[rdwebdesign]

I just remember a very confusing conversation about this.
Pinging: @DL6ER

[DL6ER]

Yes, because Debian always builds for one architecture lower. In the sense of "if you have an armv6 you can definitely run armv5 binaries". Alpine doesn't do this.

That's why

• debian/armv5 actually builds armv4 binaries,
• debian/armv6 actually builds armv5 binaries, however
• alpine/armv6 actually builds armv6

[PromoFaux]

FTL will from now on ship as fully static batteries-included binaries that can run on the irrespective of the operating system version.

Forgive my naivety on this kind of thing, but does this mean we can drop some things from the dependencies? (i.e libidn, nettle etc)

[DL6ER]

Yes, everywhere except the non-static builds (armv4 and v5)

[DL6ER]

Interestingly, it seems that the most recent commit which did nothing else than docker/build-push-action@v3 -> v4 broke the final deployment step. The deployment to Docker hub works, but not any longer to GHCR. Maybe it is a hiccup.

[yubiuser]

I checked the previous runs and compared them to the failed ones.
Usually the SHA that is pushed to Docker Hub and GHCR for each image (Alpine/Debian) should be the same. However now it tries to push another image/SHA to GHCR than to Docker Hub.

[yubiuser]

Could the issue be this line:

docker-base-images/.github/actions/merge-and-push/action.yml

Line 35 in 5c15c07

working-directory: /tmp/digests/dockerhub/${{ inputs.platform }}

Where dockerhub is hard-coded. It was never an issue before but maybe now? There should be an ghcr dir as well so maybe GHCR needs its own digests now...

[PromoFaux]

Good find. That probaly shouldn't be hardcoded there

On the docker repo I ended up doing the two registries in a matrix just to keep the file clean

https://github.com/pi-hole/docker-pi-hole/blob/2c5f02df287904ce78d1cc7cb049dcbea49c8599/.github/workflows/build-and-publish.yml#L19

https://github.com/pi-hole/docker-pi-hole/blob/2c5f02df287904ce78d1cc7cb049dcbea49c8599/.github/workflows/build-and-publish.yml#L131-L135

[DL6ER]

This seems to have fixed it. What else do we need for this PR to land? All FTL v6.0 builds are using this containers for a while: https://github.com/pi-hole/FTL/blob/4ac9f120f5750c2a179b2de86e0a35c64adbf5aa/.github/Dockerfile#L2

[yubiuser]

I think nothing. It's your PR if you think it's ready, lets us know to review.

[PromoFaux]

Miles behind on reviews and things. Sorry!