Add squash support for automated builds

[ryansanford]

The new docker build --squash is a great step once that becomes stable. That will allow us to build our docker images without leaving proprietary source code behind in the image layers without workarounds.

The next step is to provide that as a config option for automated builds in dockerhub. Without that option, we are required to use external systems for some of our Docker image builds.

[ryansanford]

Dockerhub support of multi-stage builds would also address the same pain-point.

[ghost]

I'd be happy with just a basic "additional flags" input on the build configuration page, to be honest. A checkbox for "squash" make it simple, but the input would make it a bit more extensible in the future.

[staticfloat]

Even if not an entire "additional flags" field, just a checkbox for squash would be extremely useful for me. My images go from 8GB+ to ~500MB with squashing.

[mghazizadeh]

Multi Stage build coming to Docker Cloud.

https://forums.docker.com/t/multi-stage-builds-coming-soon-to-docker-cloud/32414

[lilith]

Multi-Stage builds don't address everything that --squash does. --squash allows for cleaner Dockerfiles and faster builds (we don't have to delete caches until the last step). Docker Hub could save a lot of bandwidth and worker time by allowing us this option.

[staticfloat]

For what it's worth, I rewrote my Dockerfiles from being --squash-based to using Multistage builds and I'm pretty happy with it. I use docker to build many different configurations of gcc/llvm for a giant crosscompiler image. Without multistage builds, I had one enormous Dockerfile that got squashed down into a single ~10GB image, instead of the 150GB+ it consumed for the unsquashed version. With multistage builds, I am able to have a very flexible build system where I perform each GCC cross compilation in "shard" Dockerfiles, then just copy the resulting compiler (which I placed in /opt/<cross_compile_triplet> to a final image, and I gain many advantages by doing so:

• First off, each "shard" is independent, so if I change something in one shard, it does not force every step after it to be re-run. This is a huge time saver for me.

• Secondly, there is no longer an implicit limit on the number of steps I can have overall in my docker builds; I would routinely run into the maximum number of supported layers problems with giant images that get squashed down, but with this new system, each build stage starts over with its own layers stacked on top of whatever base image that shard is based off of.

[olemis]

Support for --squash in Docker Cloud would be nice to have because sometimes multi-stage builds are not enough . Modifications in web interface are not quite urgent since it is possible to redefine build hook. The fact is that we added --squash in a project and still we get

Building in Docker Cloud's infrastructure...
Cloning into '.'...
Switched to a new branch 'stdevNorge_t1903_docker_reduce_image'
Pulling cache layers for index.docker.io/simelotech/skycoin:feature-olemis-1835...
Done!
Executing build hook...
"--squash" is only supported on a Docker daemon with experimental features enabled
"--squash" is only supported on a Docker daemon with experimental features enabled
"--squash" is only supported on a Docker daemon with experimental features enabled
"--squash" is only supported on a Docker daemon with experimental features enabled
"--squash" is only supported on a Docker daemon with experimental features enabled
build hook failed! (1)
ERROR: Build failed: build hook failed! (1)
ERROR: Build failed with exit code 2
ERROR: Build in 'stdevNorge_t1903_docker_reduce_image:/docker/images/mainnet/Dockerfile' (bb64822a) failed in 0:01:45

[Rojo]

Multistage builds are nice for projects with only compiled binaries that can be passed around, but other projects get more benefits from squashing.

[AlexKovalchukSomatic]

Any updates?