virtool / virtool.ca

The new website for Virtool

Virtool

Virtool is a web-based application for diagnosing pathogen infections using high-throughput sequencing.

Website: https://www.virtool.ca

Getting Started

See the Virtool documentation to get started with the latest version of Virtool 4.0.0.

About Versions

Virtool is currently undergoing a major transformation into a cloud-native application. This will mean Virtool can scale work across multiple hosts and run natively in Kubernetes and public cloud providers.

For current users and administrators:

1. Virtool 4.0.0 series should be used for now.
2. Virtool 4.0.0 series will continue to receive bug and security fixes for the forseeable future.
3. Virtool 5.0.0 will comprise multiple containerized services that need to run together. A deployment and migration guide will be provided.

Tests

In the source directory root:

1. Start the required backing services in Docker.

   docker compose -f tests/docker-compose.yml -p virtool-test up -d
   

2. Run the test suite:

   poetry run pytest
   

Multiplexing

The test suite works with pytest-xdist.

poetry run pytest -n 4

This will use multiple Python processes to run the tests in parallel.

Snapshots

We use Syrupy for snapshot testing.

Snapshots are used for tests where we want to assert that an object (eg. database record, Pydantic object, API response) has an expected shape and set of values.

If snapshots need to be updated:

poetry run pytest <path_to_test_file> --su

You can be even more specific by specifying the test class or function:

poetry run pytest <path_to_test_file>::<class_or_function>

Always be specific about what snapshots you are updating. Don't blindly update a ton of snapshot files just to make your tests pass.

Commits

All commits must follow the Conventional Commits specification.

These standardized commit messages are used to automatically publish releases using semantic-release after commits are merged to main from successful PRs.

Example

feat: add API support for assigning labels to existing samples

Descriptive bodies and footers are required where necessary to describe the impact of the commit. Use bullets where appropriate.

Additional Requirements

1. Write in the imperative. For example, "fix bug", not "fixed bug" or "fixes bug".
2. Don't refer to issues or code reviews. For example, don't write something like this: "make style changes requested in review". Instead, "update styles to improve accessibility".
3. Commits are not your personal journal. For example, don't write something like this: "got server running again" or "oops. fixed my code smell".

From Tim Pope: A Note About Git Commit Messages