TB-Predict-Pipeline

Nextflow pipeline for producing variants, mutations and effects of a specified (minos) VCF file

Requirements

• Docker
• Nextflow

Running the NextFlow

Workflow takes parameters:

• seq_platform. ont or illumina (illumina by default)
• sample. path to vcf file, likely from minos (Can be gzipped)
• gvcf. Path to gvcf (can be gzipped)
• reference. reference gbk file
• catalogue. Path to mutations catalogue
• null_position. Path to list of null positions.

To save output files need to set --publish_dir which will save output files to directory provided.

Example running locally:

nextflow run . -profile local --publish_dir results --seq_platform illumina \
    --sample tests/test-cases/NC_045512.2-S_E484K-minos.vcf \
    --gvcf tests/test-cases/empty.gvcf \
    --reference tests/test-cases/NC_045512.2.gbk \
    --catalogue tests/test-cases/NC_045512.2-test-catalogue.csv \
    --null_positions tests/test-cases/no-null-positions.txt

Batch locally

To run a batch of files locally though this pipeline requires input files to be a folder structure

• directory
  • sample1
    • minos.vcf
    • minos.gvcf
  • sample2
    • minos.vcf
    • minos.gvcf

Then use entry batch, and provide globs for the samples and gvcfs

nextflow run . -entry batch -profile local --publish_dir results --seq_platform illumina \
    --samples "tests/batch_dir/*/*.vcf" \
    --gvcfs "tests/batch_dir/*/*.gvcf" \
    --reference tests/test-cases/NC_045512.2.gbk \
    --catalogue tests/test-cases/NC_045512.2-test-catalogue.csv \
    --null_positions tests/test-cases/no-null-positions.txt

Tests

As this is a very simple pipeline which just calls gnomonicus, the majority of testing occurs within gnomonicus. However, the included tests cover some edge cases of files being produced, as well as ensuring files are placed in correct places.

Run the tests

Pipelines and evaluation are run using a bash script. This should also be automatically run on each push to the main branch through a CI action. Note that this repo intentionally does not use nf-test for these tests. This is due to a few reasons, but mostly that direct file comparisons are not reliable here due to fields such as timestamp

tests/test.sh

Tags, Releases, and Committing

Use conventional commits. This is enforced with commitizen validate action and pre-commit hooks:

pre-commit install

This repo uses a standard gitflow approach, so changes should be first merged into develop and then released to main.

• In the develop branch semantic versioning is not used. Instead you can reference the commit hash to use it in a workflow.
• In a release branch you can create a release candidate with cz bump a.b.c-rcX. This also creates a tag.
• When release branch is ready for main run cz bump a.b.c --files-only. Manually write a human descriptive changelog. Then push these changes to main and make a release/tag there.