-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Most CI systems do something similar and you end up with an awful, monolithic build step that's essentially 'build-and-test-and-tag-and-push'. It's the same on every platform too. GitHub Actions, GitLab CI, Drone CI, etc. all seem to do the same thing.
What if I want to build in one environment that pushes and one environment that doesn't? In my experience it's much easier if 'push' can be a build step on it's own because the CI system will usually have conditional support for things like different environments.
From what I've seen it's not possible to use buildx and then conditionally tag the resulting images in a second command or build step. The 'docker' driver doesn't support multiarch and the 'docker-container' driver doesn't support '--load' [1], so you're pretty much stuck with a single command that does everything, at least for now, because the built images won't be added to the build daemon (ie: you won't see them with 'docker image ls'). Am I wrong?
I've always liked the way the Docker daemon uses simple commands for everything; docker pull, docker build, docker tag, etc.. It feels very unix like. It would be a shame to lose that IMO.
1. https://github.com/docker/buildx/issues/543
Another great tool for cross arch development is qemu-static-user. It allows you to run your nonnative architecture docker images on host using a qemu container for translation and only requires about one command to get working. It’s life saving for me when I need to test but setting up a full VM or native server is too time consuming.
https://github.com/multiarch/qemu-user-static