staph-b/cdphe

Various pipelines and scripts used by the CO state public health lab

cdphe's Issues

Add check to see if Docker is installed, if not, exit/kill script

Not sure what the code would look like, but this should be implemented in all dockerized scripts.

create a USAGE section on the README

Would be nice to have a USAGE section on the README.md so that if others want to use the pipelines, they have the instructions to do so.

Could include:

• Requirements / dependencies
  • local installs of tools for non-dockerized scripts
  • dockerized pipelines docker, pigz
• Details of each pipeline (what program is run?, what results should I expect to see?)
  • type_pipe
  • pipeline_non_ref_tree_build
  • lyveset
  • nanopore scripts (not really a full-fledged pipeline yet)
• Usage examples - run X script in this directory, receive Y files out, example commands to run the scripts
• Known issues and/or a to-do list
• Links to bioinformatics training videos?

Add checks for docker image versions and if they have been pulled or not

Would be good to have a check near the beginning of the dockerized scripts to see if a docker image has been pulled or not. If not, pull docker image.

I would prefer to avoid checking by running docker pull for all programs, because even if the image is present on the machine, it will still download the must up-to-date image, which may not have changed. Docker/Docker hub just thinks that the image has changed since a push to the master branch of staph-b/docker-auto-builds currently results in auto-rebuilding of ALL images

# just for illustration purposes - totally fake code
if [ docker run staphb/spades:3.12.0 spades.py -v ] returns: SPAdes v3.12.0 ; 
    print version to screen (potentially set bash variable as $SPADESVER)
else
    docker pull staphb/spades:3.12.0
fi

Would need checks for each program used by each dockerized script.

type_pipe_2.5-dockerized.sh shuffle reads wildcard bug

In line 314 of type_pipe_2.5-dockerized.sh an * is used that on my end leads to an apparent error with file names that are a substring of another file name (eg. 22 and 220) in that the resulting files for two distinct isolates are identical. Removing the * corrected the issue in my local job script.
Also, (disclaimer: I have not look into this directly) a similar problem may arise in the MASH, Kraken, and SPAdes steps as they appear to also utilize wildcards in a similar way.