mount_paths can delete a directory in the container
pickledish opened this issue · 1 comments
Description
One task A
creates a directory in a container, then a later task B
which depends on A
, when using mount_paths
, can remove that directory. I've tested and the same does not happen with input_paths
.
Instructions to reproduce the bug
Here is my Toast file. The package.json
contains Vite and some other stuff:
image: node:20
command_prefix: set -euxo pipefail
location: /scratch
tasks:
deps:
input_paths:
- package.json
- package-lock.json
command: |
npm install
dev:
cache: false
dependencies:
- deps
mount_paths:
- .
ports:
- 5173:5173
command: |
npm run dev
When trying to use toast dev
, the command fails (vite is not found), and getting a shell into the container I found that the node_modules
directory that had been created by the deps
task was gone. Replacing mount_paths
with input_paths
in the above example, changing nothing else, fixes the problem (the node_modules
dir exists and vite etc can be used).
Environment information:
$ toast -v
Toast 0.47.5
$ sw_vers
ProductName: macOS
ProductVersion: 11.7.8
BuildVersion: 20G1351
Might this be because mounting .
of the host to /scratch
inside the container overrides all existing contents in /scratch
? This would be a surprising difference between the behaviors of mount_paths
and input_paths
("for each file in this directory, copy the file into the container") which otherwise look and work the same. Anyway, if this behavior is intended, then feel free to close the issue, thanks!
Hi @pickledish, thank you for opening this issue. Unless I'm misunderstanding, this is the intended behavior and highlights one of the key differences between mount_paths
and input_paths
: mount_paths
just exposes the host file system to the container, and any changes made by containers to mounted paths (such as deleting directories) are persisted between runs. However, you can also use the mount_readonly
toastfile option if you want to disallow changes to the host file system. With input_paths
, the container is operating on a copy of the files from the host, so the files on the host are unaffected by whatever happens inside the container.