Open anti-social opened 2 years ago
I'm not against such an option, but I'm not sure what is a use case? As in my use cases I would not want to write that in command-line each time, so I would put this into an alias file, which is a close equivalent to config.
The important difference here is that adding volumes:
make volume mandatory. Which makes it harder to use for other users (they always need to have that volume). So maybe we can add optional volumes in some way?
Alternative for this solution is also:
commands:
run-ci: !Command
<<: *run-cmd
volumes:
/work/target/.cargo: !CacheDir cargo
Which works both, for new users, by putting it in .vagga/.cache/cargo
and for experienced users having shared cache by putting it somewhere in /vagga/_cache/cargo
or ~/.cache/vagga/cargo
, or wherever is configured without any intervention.
Or is your goal to unify local cache with in-container cache? Then also putting CARGO_HOME=$HOME/.cache/vagga/cargo
to your ~/.profile
is a good solution too. Making it a little bit more complex (but not more complex than --mount-bind
I think) for users really make sense because it's a bit of a security issue: if container puts malware into a cargo home, it can be executed by out of container cargo and break into your system. While using just shared cache between containers is also an attack vector, which allows attack other containers, but it's still hard to break into host system.
Possibly I've found a better use case for the option. Imagine you want to override a dependency:
dkregistry = { path="../dkregistry-rs" }
At the moment you can add your root projects directory as external volume to be able to mount it inside a container. But it is less secure as all containers will be able to see content of the projects directory.
One problem is that there is no mount point in the container if we don't create it in advance. As a workaround we could mount such an external directory inside your /work
directory.
At the moment we can emulate such a behavior:
vagga.yaml
:Think it is too complex to be really useful.
Possible options:
--mount-bind
--mount-bind-ro
--mount-tmpfs
--mount-snapshot
Either we can have a single
--mount
option and pass mount type encoded inside an argument.