Better support for build caches

[rlupton20]

Some build tools like to persist build data to disk. It would be nice if floki allowed build caches created inside the container to persist between container launches, and even across containers in different which might want to share a cache (e.g. Rust builds).

Caches should work even if the user hasn't configured them (as in, they should do something sensible if enabled, and not rely on the users environment), but it may be worthwhile allowing users to set a particular file directory for a cache.

[rlupton20]

Currently proposing a new YAML field as below:

volumes:
  key:  # only used if the volume is shared, otherwise, just a useful piece of documentation
    shared: false  # optional, defaulting to false
    mount: /path/to/mount/inside/container

Folders will be created in ~/.floki/volumes as needed, using a name unique to the base directory, unless the volume is shared. An extension can then be made to allow floki to use shared volumes with configurable path, along with suitable CLI backing to make it configurable. Something like:

floki volume rust --set $CARGO_HOME

This gives the following steps:

[x] Provide basic volume support in floki. [] Allow shared volumes to have configurable host paths, set in a file [] Provide additional command line control over cache paths

[rlupton20]

@bossmc - will probably get started on this tomorrow, but this is roughly what I'm thinking.

[bossmc]

Sounds good to me! Presumably if a floki.yaml asks to mount a shared volume that doesn't exist then it will be created but not backed by a host-path?

[rlupton20]

I was thinking of backing it with a host path, creating it as needed. It can be overiden later, or we could provide some kind of merge strategy (but that might be overkill).

[bossmc]

:+1:

[rlupton20]

@bossmc on the linked PR I have some basic volume support (the first tick box above). It's not quite polished yet - it creates folders with the user permissions (not with setgid() though), but if you want to take it for a spin for some early feedback that might be useful.

Also this won't work with dind yet - I probably want to refactor the dind implementation because it's currently gross as all hell.

You an run with -vvv if you want to see what's going on under the covers.

[rlupton20]

Actually, I'm not sure if in general we'd want things automatically mounted into dind. I might opt to make it configurable (having just done the refactoring required to make it easy).

[rlupton20]

(My initial testing has successfully bound a rust registry - no rebuilds when relaunching the container!)

[bossmc]

Just did a bit of testing, and so far all seems good. I even tested the hack we discussed on slack (symlinking from my real registry to the volume under .floki/cache) and that works excellently:

$ ln -sf ~/.cargo/registry /home/andy/.floki/cache/
$ cat floki.yaml 
image: rust-dev:latest
shell: bash
volumes:
  registry:
    shared: true
    mount: /opt/rust/registry
$ floki
# time cargo search --registry crates-io foo
...
real	0m0.449s
user	0m0.029s
sys	0m0.017s

Without the mounted registry this takes ~2 mins.

[rlupton20]

Cool. I think I'm happy with what I have as a first chunk of work, so after a review and a bit more testing I'll probably get it merged.

[rlupton20]

I just merged #36 , so that gives the core volume support.

[rlupton20]

I think the next step I want to take here is to add a simple subcommand to list out the volumes and their backing paths. This ought to make tracking the symlinking either scriptable (with some awking), or at least easier.

I also realised I obnoxiously decided to use ~/.floki as a work folder, whereas we probably ought to respect the open desktop specification (and use e.g. ~/.cache/floki). Not sure how much I care, but just noting it.