Best Practices for Creating WDLs

There are opportunities to participate in code reviews with other WDL developers. ContactUs

Templates

WDL Best Practices Template

# By versioning your WDL, you specify which specification cromwell uses to decifer the WDL.
# New features come with new versions.
version 1.0

# import any subworkflows
import "subworkflow.wdl" as firstStep

workflow bbtools {
    meta {
        authors: [
            {
                name: "Jackson Brown"
                email: "jbrown@my-inst"
                organization: "JGI"
            }
        ]
        version: "2222.2.0"
        notes: "this is the official release version"
    }

    # you must have this input section within the "workflow" stanza if you are using version 1
    input {
        File reads
        File ref
        String docker_image = "jfroula/bbtools@sha256:cf560d21149237feff9210b0cd831dcc532ebdccaaa3f5ede52369f45a23e768"
    }

    call firstStep {
      input: fastq=reads,
             docker_image=docker_image
    }

    call alignment {
       input: fastq=reads,
              fasta=ref,
              docker_image=docker_image
    }

    call samtools {
       input: sam=alignment.sam
   }
}

#
# below are task definitions
#
task alignment {
    # Metadata is good for helping the next guy understand your code.
    # This meta section can also be used for documentation generated by wdl-aid.
    # You can run "wdl-aid <workflow.wdl>" if it is installed, see https://wdl-aid.readthedocs.io/en/latest/usage.html)
    meta {
        metaParameter1: "Some meta Data I"
        metaParameter2: "Some meta Data II"
        description: "Add a brief description of what this task does in this optional block. One can add as much text as one wants in this section to inform an outsider to understand the mechanics of this task."
    }

    input {
        File fastq
        File fasta
        String docker_image
    }

    command <<<
        # Use this command to help debug your bash code (i.e. prevents hidden bugs).
        # For a description, see https://gist.github.com/mohanpedala/1e2ff5661761d3abd0385e8223e16425
        set -euo pipefail

        # Note that ~{} is prefered over the old ${} syntax
        bbmap.sh in=~{fastq} ref=~{fasta} out=test.sam
    >>>

    runtime {
        docker: docker_image
        cpu: 8
        memory: "5GB"
        runtime_minutes: 120
    }

    output {
       File sam = "test.sam"
    }

    # This section is optional and used to create documentation using the wdl-aid tool.
    # see https://wdl-aid.readthedocs.io/en/latest/usage.html
    # You can run "wdl-aid <workflow.wdl>" if it is installed.
    parameter_meta {
        fastq: {description: "file containing reads", category: "required"}
        fasta: {description: "file containing referenece sequences", category: "required"}
        docker_image: {description: "docker image containing BBTools", category: "required"}
    }

}

Additional helpful notes when building Docker images:

The dockerfile template uses the strategy of installing miniconda so you can use conda install for probably, most of your tools. However, pip install and apt-get install work in addition to, or instead of miniconda.
Also, remember to use versions of everything you install with conda as shown in above docker template example.
There is a good reason to install miniconda in a path other than its default. The default installation directory is /root/miniconda3 but this path will not be accessible by shifter or singularity.
When you build your docker image (i.e. docker build --tag <somename> -f ./Dockerfile3 .), all files in the current directory (and sub-directories) are transfered to the local docker daemon. This transfer step can be time consuming. Therefore, docker builds should be performed in a directory without extraneous files.
One helpful thing you can do when developing docker images is to create a bare essentials image with your favorite editor installed (i.e. vim). Then you can go into the container interactively docker run --it <image> and see if you can install stuff manually, then just copy those same commands into the final dockerfile.

For more see the docker official docs on best practices.