Nextstrain build for novel coronavirus SARS-CoV-2

Developer guide


  1. Setup
  2. Data
  3. Running
  4. Releasing new workflow versions


Please see the main Nextstrain docs for instructions for installing the Nextstrain bioinformatics pipeline (Augur) and visualization tools (Auspice).


In order to run the Nextstrain build you must provision ./data/sequences.fasta and ./data/metadata.tsv. We’ve included a test set of sequences that are publicly available via Genbank as ./example_data/sequences.fasta.


Please see these docs for instructions on how to run this build yourself.

The resulting output JSON at auspice/ncov.json can be visualized by running auspice view --datasetDir auspice or nextstrain view auspice/ depending on local vs containerized installation.

Finalizing automated builds

To run a regional build, be sure to update the list of regions in nextstrain_profiles/nextstrain/builds.yaml. You can run all builds in parallel with the following command.

snakemake --profile nextstrain_profiles/nextstrain all_regions

Or you can specify final or intermediate output files like so:

# subsampled regional focal
snakemake --profile nextstrain_profiles/nextstrain auspice/ncov_europe.json

# subsampled global
snakemake --profile nextstrain_profiles/nextstrain auspice/ncov_global.json

To update ordering/lat_longs after AWS download:

snakemake --touch --forceall --profile nextstrain_profiles/nextstrain
snakemake --profile nextstrain_profiles/nextstrain clean_export_regions
snakemake --profile nextstrain_profiles/nextstrain export_all_regions

When done adjusting lat-longs & orders, remember to run the following command to produce the final Auspice files.

snakemake --profile nextstrain_profiles/nextstrain all_regions

Releasing new workflow versions

We use semantic versioning of the ncov workflow, denoting backward incompatible changes with major versions. Prior to merging a pull request that introduces a new backward incompatible change (e.g., requirement of a new version of Augur), take the following steps to document these changes:

  1. Determine the new version number by incrementing the current version (e.g., “v2” from “v1”).
  2. As part of the pull request, document the change(s) from the pull request in docs/ with the current date and new version number.
  3. Merge the pull request
  4. Create a new GitHub release using the new version as the tag (e.g., “v2”) and release title. Leave the release description empty.

We do not release new minor versions for new features, but you should document new features in the change log as part of the corresponding pull request under a heading for the date those features are merged.