Currently, because of the dogen/concreate tool and the fact that the Dockerfile (that is actually generated by the dogen/concreate tool, but at the same time is part of the repo(?)) isn't optimal and creates some extra layers, the images are 250 megs larger than they should be.
If we migrate from automatic {dockerhub|quay} builds that are currently based on a git push trigger and they build that sub-optimal Dockerfile; to something in Travis CI, we could also run the docker-squash tool and instead of 900MB the image would be 650MB. Using the same (generated) Dockerfile.
To be honest, I'd rather see using the Dockerfiles as a "single source of truth" instead of those yaml descriptors that are kind of Red Hat specific and are there only for productization / dogfooding efforts :) but I am being realistic and it's much quicker to "fix" that image size using the travis and docker-squash.
Currently, because of the dogen/concreate tool and the fact that the Dockerfile (that is actually generated by the dogen/concreate tool, but at the same time is part of the repo(?)) isn't optimal and creates some extra layers, the images are 250 megs larger than they should be.
see also: https://github.com/radanalyticsio/spark-operator/pull/194#discussion_r257681923
If we migrate from automatic
{dockerhub|quay}
builds that are currently based on a git push trigger and they build that sub-optimal Dockerfile; to something in Travis CI, we could also run thedocker-squash
tool and instead of 900MB the image would be 650MB. Using the same (generated) Dockerfile.To be honest, I'd rather see using the Dockerfiles as a "single source of truth" instead of those yaml descriptors that are kind of Red Hat specific and are there only for productization / dogfooding efforts :) but I am being realistic and it's much quicker to "fix" that image size using the travis and docker-squash.