Docker images are by default constrained to 10GB

[TheChymera]

The SAMRI .gentoo docker_image generation process, fails with:

builder /usr/share/gebuilder/roots/06efa8964d90b8c7e3dc8718d7e8aff5148601488a48569d84c9e8fac2dc9cc3 # docker build -t 06efa8964d90b8c7e3dc8718d7e8aff5148601488a48569d84c9e8fac2dc9cc33:1519326146 .
Sending build context to Docker daemon  11.61GB
Step 1/4 : FROM scratch
 --->
Step 2/4 : WORKDIR /
 ---> Using cache
 ---> 0e2d6a678c8e
Step 3/4 : ADD root/ /
failed to copy files: failed to copy directory: Error processing tar file(exit status 1): write /usr/share/doc/fsl-5.0.9/wiki/attachments/basil(2f)COSTAID/COSTAID_Toulouse.zip.bz2: no space left on device

This can be fixed by running (adapted from this guide):

rc-service docker stop
dockerd --storage-opt dm.basesize=25G
<Ctrl+C - for some reason this does not terminate by itself, though the guide implies it shouls>
rc-service docker start

@Doeme any idea how we could more elegantly/automatically deal with this? Perhaps checking the exit status of docker build -t ... and attempting to resize the baseimage if it fails?

[Doeme]

I have a feeling like this is none of gebuilders business. We could try to remove stuff the image does not necessarily need, but this only postpones the problem. Maybe note somewhere: "adapt docker storage baseize size if you plan on building oversized images."

[TheChymera]

Yeah, I was also on the fence regarding in how far we should micromanage our deps. we could just pin it to the known issues.

[Doeme]

I think at most we could bail out earlier, if we notice the image is too large.

[TheChymera]

that would also involve docker basesize monitoring, if we do anything at all about it, I'd favor a more Pythonic approach where we ask for forgiveness, not for permission. Given the general duration of builds large enough to cause problems, I don't think saving 5' here is really that big a deal.

[TheChymera]

I added an example pre hook for gebuilder /path/to/.gentoo docker_image to address this issue.