You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ContainerInvalidSettings when using --pull=always #139
When launching a task with container_run_options='--rm --pull=always --workdir=/app'. The task fails with a ContainerInvalidSettings error. Saying the --pull=always is not valid. Is this behaviour blocked on purpose, or is this a bug?
I just checked the sources and it is indeed not parsed which is generating the error. I will check with the author if this was on purpose. I suspect it may be since when using containers in batch the pull is actually done outside of the "docker run" command. Container pulls happen at the VM level or at the task level when you specify which container to execute in. Batch will pull the container for you prior to invoking the docker run on behalf of your task.
Thanks for the quick response! It is probably a bit of a niche use case. As we want to keep one VM running for quicker response times, however this means the docker image could be updated in the meantime. So just to be safe I would like the tasks to always pull the latest image.
Ah ok, this makes sense as the way the implementation currently works is to just check locally for the container image, and if it doesn't exist pull it. Your use case makes sense though.
Activity
staer commentedon Oct 7, 2022
I just checked the sources and it is indeed not parsed which is generating the error. I will check with the author if this was on purpose. I suspect it may be since when using containers in batch the pull is actually done outside of the "docker run" command. Container pulls happen at the VM level or at the task level when you specify which container to execute in. Batch will pull the container for you prior to invoking the docker run on behalf of your task.
JulesHuisman commentedon Oct 7, 2022
Thanks for the quick response! It is probably a bit of a niche use case. As we want to keep one VM running for quicker response times, however this means the docker image could be updated in the meantime. So just to be safe I would like the tasks to always pull the latest image.
staer commentedon Oct 7, 2022
Ah ok, this makes sense as the way the implementation currently works is to just check locally for the container image, and if it doesn't exist pull it. Your use case makes sense though.