Set docker_enabled and docker tag for eu tools that can only run with docker #18
Conversation
|
It shouldn't matter but I guess it would be nice to change the formatter to send those to the top. |
| @@ -2293,6 +2307,13 @@ tools: | |||
| mem: 8 | |||
| Extract genomic DNA 1: | |||
| cores: 3 | |||
| __docker_tool: | |||
There was a problem hiding this comment.
I think it may make sense to rename this to __docker_only_tool, as most tools can run with docker. Also, would this run with singularity also? If so, perhaps it should be renamed to container_only_tool?
| __docker_tool: | |
| __docker_only_tool: |
In general, I've been wondering about the best way to support docker, especially for scenarios like these where the container hasn't worked and we've had to override it manually: https://github.com/galaxyproject/galaxy-helm/blob/697f744f1258f5efccaf52cc3be79e1177ad79fc/galaxy/values.yaml#L524
There was a problem hiding this comment.
That's a very good point. These tools all have only a docker type requirement in the tag but I forgot that these tools can also run with singularity, so setting require: [docker] is too restrictive, as is setting the docker_enabled param. I don't know if this PR makes sense - perhaps this logic belongs in local configuration.
There was a problem hiding this comment.
What if we just rename require: [docker] to require: [container]? The specific configuration for which container etc. is left to local configuration.
I think this information being in the shared database is useful, because you can't realistically expect to run these tools otherwise?
@nuwang will it matter that the abstract tool being inherited is lowest in the list?