Fix 'no space left on device' while building the container image

[avisiedo]

This fix the root cause that was evoking the following error in the pipeline:

STEP 9: FROM gcr.io/distroless/static:nonroot
Getting image source signatures
Copying blob sha256:9e4425256ce4503b2a009683be02372ee51d411e9cc3547919e064fee4970eab
Copying config sha256:88055b6758df5ed37dc68692e2c8ffefc165a22f544896b3277dc414ec03ea37
Writing manifest to image destination
Storing signatures
time="2021-02-14T20:23:47Z" level=error msg="error deleting build container \"df8c632a13d29af04315af8f188588977ab136998bff6dd379005b9fb0a4bd80\": identifier is not a container\n"
Error: identifier is not a container: error preparing container for next step: error creating build container: error creating container: error creating read-write layer with ID "d33634e43f97af7168ee18a546c1addaf872380761e6b48bb49d918352cb5c97": no space left on device
make: *** [Makefile:119: container-build] Error 125
Error: Process completed with exit code 2.

By shrinking the size of the resulting layer while building the container image.

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: avisiedo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/freeipa/freeipa-operator/blob/master/OWNERS)~~ [avisiedo] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[frasertweedale]

@avisiedo does this mean the disk space in the pipeline execution environment is very constrained? Do we know what the limits are, or if it is possible to relax the limits?

[avisiedo]

@frasertweedale Yes, it is limited.

I have collected some information from the pipeline from my forked repository: https://github.com/avisiedo/freeipa-operator/runs/1899877766?check_suite_focus=true#step:6:68

>>> Building container image
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        84G   64G   21G  76% /
devtmpfs        3.4G     0  3.4G   0% /dev
tmpfs           3.4G   12K  3.4G   1% /dev/shm
tmpfs           696M  1.1M  695M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.4G     0  3.4G   0% /sys/fs/cgroup
/dev/sda15      105M  3.9M  101M   4% /boot/efi
/dev/loop1       56M   56M     0 100% /snap/core18/1944
/dev/loop2       56M   56M     0 100% /snap/core18/1988
/dev/loop0      138M  138M     0 100% /snap/chromium/1479
/dev/loop3      163M  163M     0 100% /snap/gnome-3-28-1804/145
/dev/loop4       32M   32M     0 100% /snap/snapd/10707
/dev/loop6       70M   70M     0 100% /snap/lxd/19188
/dev/loop7       32M   32M     0 100% /snap/snapd/11036
/dev/loop5       65M   65M     0 100% /snap/gtk-common-themes/1514
/dev/sdb1        14G  4.1G  9.0G  32% /mnt
podman build . -t ***:da4014ad9a4f83da81a4db6446003cfbe87a5255

I did changes for releasing space before build the container image with no success.

At the end, I restructured the Dockerfile steps to minimize the size for the generated layer.

Honestly I don't know exactly which is the limitation that was evoking this issue. I would need further investigation as running "podman info" to see where is the storage location.

[frasertweedale]

Clear documentation about capacities of GitHub actions environments was not easy to find. But I found this:

https://docs.github.com/en/actions/reference/specifications-for-github-hosted-runners.

It says there is a 14GB disk space. (I suppose that's what's mounted at /mnt?) But 4GB is already consumed (I saw suggested in a different place that it is a swap file). And then, is the 21GB in the /dev/root device usable? Where is $HOME? located. Where do containers get created?

All a bit vague and underspecified...