Template structure

The template employs a basic framework that allows users to customise and extend the workflow while adhering to code management best practices.

The workflow code-base is organised into a number of different executable files and directories. This organisaiton promotes code modularity, reusability, maintainability, and clarity. Each executable file included in the template contains comment lines, links to relevant Nextflow documentation, and implementation examples. To apply the template to your own workflows, you will need to replace examples with your own code.

Modularising the code base and splitting workflow processes and configuration files offers a few benefits:

  • Code organisation and maintainability
  • Readability and clarity
  • Collaboration
  • Testing and debugging
  • Code reuse and extensibility

Nextflow is highly flexible, allowing users to implement workflows in a number of different ways. In this template, we provide one common implementation for structuring your Nextflow code base in a way that is easy to maintain and read.

The template’s code repository is organised into a number of files and directories:

myWorkflow-nf
├── .github/ISSUE_TEMPLATE
├── assets
├── bin
├── config
├── modules
├── main.nf
├── LICENSE
├── README.md
└── nextflow.config

Consider a basic Nextflow run command below, where a user will need to specify parameters and (optionally) a configuration profile:

  • The main.nf file is the executable file that identifies the workflow structure, inputs, and processes to pull form the modules/ directory.
  • The --parameter flag matches a parameter initialised in the nextflow.config file and applies it to the workflow execution.
  • The -profile flag is used to specify environment-specific configuration details such as a software implementation method and/or resource management.

Running a workflow that follows this template will output:

  • A customisable execution message invoked when the workflow is run
  • A customisable help message invoked using --help or failing to supply a required parameter
  • A customisable completion message invoked when the workflow has finished running
  • Files generated by your processes, optionally these can be saved to a results directory
  • Workflow execution resource usage, trace, and timeline reports