Closed Al2Klimov closed 1 year ago
@julianbrost Can we split the Intel/ARM builds like this, docker push and.. everything will land together on DH?
I don't know, I also used buildx for the first time this week. But I hope that should be possible.
Also, why drop ccache? Should be quite easy to use now and would be very helpful for local builds: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/syntax.md#run---mounttypecache
Do you agree that it makes sense to build x64 on x64, arm* on arm64 and then merge them together?
If you'd have the infrastructure for it, yes. What I'm currently playing around with won't allow you to run privileged containers in the end, so that won't work here.
OK, new findings:
docker buildx build seems to be designed to get all targets via --platform and to directly --push the image into the registry.
That seems to work.
Shall we just go that way?
docker buildx build seems to be designed to get all targets via --platform and to directly --push the image into the registry.
In the meantime, I also learned this. I feel like I should also have mentioned this before somewhere.
Shall we just go that way?
If we want ARM support, I'd say that's the way to go. Also, the build time of just over 2h for all 3 architectures sounds quite acceptable (especially when compared to the over 4h for Raspbian packages).
In short, I completely re-designed this. I'd checkout the tree and look top-down.
the GHA-GHA test this GHA's build.bash, with all of course
I don't understand what this is trying to say.
Actually it's just this change: https://github.com/Icinga/docker-icinga2/pull/73/files#diff-5c3fa597431eda03ac3339ae6bf7f05e1a50d6fc7333679ec38e21b337cb6721R27
Dockerfile does the compiling, so no ccache
That's no longer a limitation when building directly from a
Dockerfile
: https://docs.docker.com/engine/reference/builder/#run---mounttypecacheAlso, this is somewhat important for my development workflow.
We can't just hardcode absolute paths there, can we?
We can't just hardcode absolute paths there, can we?
The hardcoded paths are inside the container, so yes we can. If I understand it correctly, that cache won't be shared with the build host but rather just between container builds. But that's fine, compiler and system headers probably won't match exactly between host and container (unless you run the exact same version of Debian).
➜ docker-icinga2 git:(feature/arm-27) ✗ git diff
diff --git a/mktags.bash b/mktags.bash
index 7deffa4..5d59cc2 100755
--- a/mktags.bash
+++ b/mktags.bash
@@ -1,6 +1,6 @@
#!/bin/bash
# Icinga 2 Docker image | (c) 2023 Icinga GmbH | GPLv2+
-set -exo pipefail
+set -eo pipefail
if [[ "$1" =~ ^v((([0-9]+).([0-9]+)).[0-9]+)$ ]]; then
XYZ="${BASH_REMATCH[1]}"
@@ -8,7 +8,7 @@ if [[ "$1" =~ ^v((([0-9]+).([0-9]+)).[0-9]+)$ ]]; then
X="${BASH_REMATCH[3]}"
Y="${BASH_REMATCH[4]}"
- BUILDX=(docker buildx build --platform "$(cat "$(realpath "$(dirname "$0")")/platforms.txt")" --push)
+ BUILDX=(echo docker buildx build --platform "$(cat "$(realpath "$(dirname "$0")")/platforms.txt")" --push)
cd "$(mktemp -d)"
echo "FROM icinga/icinga2:$XYZ" >Dockerfile
➜ docker-icinga2 git:(feature/arm-27) ✗ ./mktags.bash v2.12.1
docker buildx build --platform linux/amd64,linux/arm/v7,linux/arm64/v8 --push -t icinga/icinga2:2.12 .
➜ docker-icinga2 git:(feature/arm-27) ✗ ./mktags.bash v2.13.1
docker buildx build --platform linux/amd64,linux/arm/v7,linux/arm64/v8 --push -t icinga/icinga2:2.13 .
docker buildx build --platform linux/amd64,linux/arm/v7,linux/arm64/v8 --push -t icinga/icinga2:2 .
docker buildx build --platform linux/amd64,linux/arm/v7,linux/arm64/v8 --push -t icinga/icinga2 .
➜ docker-icinga2 git:(feature/arm-27) ✗
fixes #27