Extra bits

There are multiple files and directories in this template. When downloaded, the template’s codebase is organised into the following directories and files. As you go through the template, you’ll notice a number of README.md files that explain what should be placed in the directory. Additionally, note:

• .github/ISSUE_TEMPLATE
• assets/
• LICENSE
• README.md

Note

We highly recommend Nextflow’s Advanced Training materials to support your learning and implementing this template.

.github/ISSUE_TEMPLATE

GitHub issues are items that you and visitors to your code repository can use to plan, track, and discuss your code. By default these are all blank, however you can use templates to organise issues into different categories. For our purposes, we have organised issues into:

• Bug report: to track and resolve problems in the code that cause it to not run as expected.
• Feature request: to suggest new ideas or features to be added to the workflow.
• Question: for general queries.
• Blank issue: for everything else.

In .github/ISSUE_TEMPLATE you’ll find four markdown files (.md), one each for the bug report template and feature request template. You’ll also find a config.yml which can be customised for your purposes.

These files are rendered in your GitHub repository website. For example, in one of our workflows, we’ve used only the bug report and feature request templates:

Important

The .github/ISSUE_TEMPLATE directory and its contents can be removed without impacting the functionality of your workflow.

For details on how to customise these issue templates, see GitHub’s documentation.

assets/

You can store auxillary files that your workflow may use in here. We don’t recommend storing data in your git repository but if you had a samplesheet you’d like to use for automated testing then it could be placed here. Additionally, you may wish to store the following:

• Multiqc config yaml files
• Logo image files
• Email templates (e.g. nf-core/sarek email .txt and .html)
• Parameter json schema

For example, in one of our workflows, we’ve included a MultiQC custom configuration file in the assets/ directory. We’ve then referenced this configuration file inside the MultiQC module file and provided a direct path to its location as a variable:

process multiqc {
    tag "GENERATING REPORT: ${params.cohort_name}" 
    publishDir "${params.outdir}/multiqc", mode: 'symlink'
    container 'quay.io/biocontainers/multiqc:1.21--pyhdfd78af_0'

    input:
    path (multiqc_in)
    path(params.multiqc_config)
    
    output:
    path("*.html")
    path("*_data")
    path("*_plots")

    script: 
    def args = task.ext.args ?: ''
    def multiqc_config = "${baseDir}/assets/multiqc_config.yml"
    """
    multiqc . \
        --filename ${params.cohort_name}_multiqc \
        -c ${multiqc_config} \
        $args
    """
}

LICENSE

The LICENSE file provides legal information about how your workflow code can be used, shared, and modified by others. This is important because it sets the terms and conditions under which your workflow or code can be distributed. In this template, we have included an open-source license, GNU GENERAL PUBLIC LICENSE, which is a popular choice for scientific software as it allows users to freely use, modify, and distribute the code.

Ensure you choose a license that fits your project’s goals. See here for a registry of open source license options.

README.md

The README.md file is the primary documentation for your project and should provide an introduction, instructions on how to use the workflow, and additional context that potential users or contributors will find helpful. By maintaining a well-documented README.md, you’ll make it easier for others to understand and use your workflow.

Here, we have used Australian BioCommons’ workflow documentation template.