Add cross-compilation for shipping service

[svrnm]

Changes

Related to #709, this enables cross-compilation (arm64 target on amd64 build) for the github build workflow. It brings down the build time for the shipping service on both platforms to ~6min (from 1h14min). There are 2 disadvantages two that:

• The Dockerfile becomes complicated (there is probably a way to optimize that, but look at that mess...)
• The final image is not based on alpine anymore but debian slim, because cross-compiling with musl (and without glibc) didn't work for a variety of reasons, so the final image is bigger (97.8MB)

I raise this as a draft PR because this only becomes valuable when other long running builds are reduced accordingly, so merging it is not yet reasonable. The purpose of the PR right now is to discuss if the disadvantages (especially the first one) are worth the effort (assuming something similar can be done for the Quote, Payment & Currency-Services)

[svrnm]

taking this out from Draft state for now. As a note: there is an alternative ways on how to structure this: Conditional stages using build arguments.

By introducing a build argument (e.g. BUILDER_TYPE) one can have 2 different stages for native & cross compilation, looks like this:

ARG BUILDER_TYPE=native
FROM rust:1.61 as builder-native
# native compilation
...
FROM --platform=${BUILDPLATFORM} rust:1.61 as builder-aarch64_on_x86
# cross compile
...
FROM builder-${BUILDER_TYPE} as builder
...
FROM debian:bullseye-slim as release
COPY --from=builder /app/target/release/shippingservice /app/shippingservice
...

The advantage is a clearer set of docker instructions per stage
The build argument needs to be set in the github workflow

Which one do people prefer?

[cartersocha]

131s vs. 105s for me.

When you do a full demo build the docker log goes a bit nuts but I think that's intended with the cross compilation

[austinlparker]

taking this out from Draft state for now. As a note: there is an alternative ways on how to structure this: Conditional stages using build arguments.

By introducing a build argument (e.g. BUILDER_TYPE) one can have 2 different stages for native & cross compilation, looks like this:

ARG BUILDER_TYPE=native
FROM rust:1.61 as builder-native
# native compilation
...
FROM --platform=${BUILDPLATFORM} rust:1.61 as builder-aarch64_on_x86
# cross compile
...
FROM builder-${BUILDER_TYPE} as builder
...
FROM debian:bullseye-slim as release
COPY --from=builder /app/target/release/shippingservice /app/shippingservice
...

The advantage is a clearer set of docker instructions per stage The build argument needs to be set in the github workflow

Which one do people prefer?

Honestly, I don't feel like the Dockerfile is that confusing as-is; I'd lean towards accepting it as stands in order to avoid adding a special case for the build scripts.

[julianocosta89]

In my case it went from 990s to 255s (WSL - Ubuntu 20.04)
Great improvement!