Build cache efficiency: use multi-stage builds?

[jayaddison]

Currently both the backend and frontend containers are each built from single-architecture Alpine Linux system images.

Some build-time dependencies (for example, package managers) are required from the system image in each case. However, most (if not all?) of the services that these build-time dependencies are providing should result in binary-identical files regardless of the build architecture.

If that's the case, then there is a large opportunity for build cache efficiency improvements. Currently each image build begins with an architecture-specific Alpine Linux image (via the FROM clause), meaning that there is little cache re-use between builds.

Instead we may be able to build an architecture-independent filesystem image using a single architecture, and then incorporate that into multi-stage builds that 'merge in' the system binaries from the appropriate Alpine Linux architecture to produce an architecture-specific output.

The buildah tooling does appear to support multi-stage builds.

Edit: update frontend and backend Containerfile references

[jayaddison]

Here's a good explainer about multi-stage builds: https://blog.alexellis.io/mutli-stage-docker-builds/

To make the goal of this thread somewhat more practical: with carefully designed multi-stage builds, we should be able to avoid repeat retrieval and installation of Grocy source, yarn, and composer dependencies for each architecture during multi-architecture OCI builds.

However: in rare circumstances it could still make sense to perform the build on each architecture from scratch. The main idea I have in mind there would be to help identify architecture-specific bugs.