Cirrus-ci-docs: Managing volumes from cirrus.yml

[tomverin]

In order to save time and to share data between tasks we would like to be able to manage volumes

Use cases:

1. Mount a tmpfs volume to speed up build times (using emptyDir and emptyDir.medium field to "Memory")
2. Checkout a repository that is used in multiple tasks: first task stores it in a volume and then we mount it in subsequent tasks

[fkorotkov]

1. Have you considered to use VMs with Local SSDs for your GKE clusters? Local SSDs are super fast. There is a plan to move Linux Community Cluster to them. 😅

2. Have you tried to set CIRRUS_CLONE_DEPTH environment variable to let's say 1?

[tomverin]

Hi Fedor,
Thanks for the quick reply.

Since our builds are pretty small in size, and we want maximum speed we don't want to use SSD because the fastest operations comes with the biggest SSD size and thus the biggest pricing, so using memory volumes he's a good trade off to get very fast speed while buying slow disks.

And for the clone depth, we're using sonarqube and we need the clone depth to be able to see changes in the code.

[fkorotkov]

Got it, thank you! 1 is pretty doable but 2 is not that clear at the moment. There are some ideas to have a way to persist a "workspace" and pass it through out the build to different tasks but nothing concrete at the moment. BTW it most likely will be only container based feature since it will be on top of k8s primitives.

[tomverin]

Container based feature is good, because on VM I can setup tmpfs via mount with an init script.

[tomverin]

And for clone-depth 1, we might use it to be able to speed up certain tasks which do not need the full depth of the repo. Thanks for the advice.

[fkorotkov]

@tomverin you can now try

gke_instances:
  use_in_memory_disk: true
  ...

Note that memory for the tmpfs disk will be half of node's RAM and not half of a container memory limit.

[fkorotkov]

Will close this issue in favor of #85

[simonbrandhof]

@fkorotkov you recommend to directly edit the environment variable CIRRUS_CLONE_DEPTH. That sounds strange to me. The CIRRUS_* variables should be read-only and provide the effective values IMHO.
If it really works then I suggest to clarify the documentation.

[fkorotkov]

@simonbrandhof good point. Separated them in documentation.

[dbolkensteyn]

@fkorotkov To properly close this issue, could you also add use_in_memory_disk to the documentation?

Also, is the whole container's writable layer going to be on RAMDisk? I checked the other day Docker's documentation and that did not seem to be supported. I am asking because I do not see how one specifies the mounting path of the RAMDisk, i.e. volumeMounts.mountPath in Kubernetes.

[fkorotkov]

@dbolkensteyn the emptyDir will be mounted into /tmp so only /tmp where $CIRRUS_WORKING_DIR is will be in memory. I've added documentation here: https://cirrus-ci.org/guide/supported-computing-services/#kubernetes-engine