Currently the workspace bind mount is overwritten when setting the volumes property in the steps' options field.
Popper Version: 2020.09.1
Minimal Working Example:
$ cat wf.yml
steps:
- uses: "docker://alpine:3.11"
options:
volumes:
- /dev/zero:/tmp/test
args: ["cat", "wf.yml"]
$ popper run -f wf.yml
[1] docker pull alpine:3.11
[1] docker create name=popper_1_c25e08ff image=alpine:3.11 command=['cat', 'wf.yml']
[1] docker start
cat: can't open 'wf.yml': No such file or directory
ERROR: Step '1' failed ('1') !
This behavior can be worked around by using docker-py's mount option instead of the volumes option, but the behavior of the volumes option seems unintuitive to me.
This pull request retains the workspace mount, by appending it to the volumes list after the update call with the step specific options.
In case anyone else stumbles over this behavior before this behavior is changed (or if the behavior is intentional) the following workflow works as intended. However, keep in mind that the mounts option requires you to specify the mount type, which would be inferred when using the volumes option.
Currently the workspace bind mount is overwritten when setting the volumes property in the steps' options field.
Popper Version: 2020.09.1
Minimal Working Example:
This behavior can be worked around by using docker-py's mount option instead of the volumes option, but the behavior of the volumes option seems unintuitive to me.
This pull request retains the workspace mount, by appending it to the volumes list after the update call with the step specific options.
In case anyone else stumbles over this behavior before this behavior is changed (or if the behavior is intentional) the following workflow works as intended. However, keep in mind that the mounts option requires you to specify the mount type, which would be inferred when using the volumes option.