virtool

virtool

virtool est une application Web permettant de diagnostiquer les infections pathogènes à l'aide du séquençage à haut débit.

Site Web : https://www.virtool.ca

Commencer

Consultez la documentation virtool pour démarrer avec la dernière version de virtool 4.0.0.

À propos des versions

virtool subit actuellement une transformation majeure en une application cloud native. Cela signifie que virtool pourra faire évoluer son travail sur plusieurs hôtes et s'exécuter de manière native dans Kubernetes et les fournisseurs de cloud public.

Pour les utilisateurs et administrateurs actuels :

1. La série virtool 4.0.0 doit être utilisée pour le moment .
2. La série virtool 4.0.0 continuera de recevoir des correctifs de bogues et de sécurité dans un avenir prévisible.
3. virtool 5.0.0 comprendra plusieurs services conteneurisés qui doivent fonctionner ensemble. Un guide de déploiement et de migration sera fourni.

Essais

Dans le répertoire source racine :

1. Démarrez les services de support requis dans Docker.

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

2. Exécutez la suite de tests :

    poetry run pytest
   

Multiplexage

La suite de tests fonctionne avec pytest-xdist .

 poetry run pytest -n 4

Cela utilisera plusieurs processus Python pour exécuter les tests en parallèle.

Instantanés

Nous utilisons Syrupy pour les tests d'instantanés.

Les instantanés sont utilisés pour les tests où nous voulons affirmer qu'un objet (par exemple, enregistrement de base de données, objet Pydantic, réponse API) a une forme et un ensemble de valeurs attendus.

Si les instantanés doivent être mis à jour :

 poetry run pytest <path_to_test_file> --su

Vous pouvez être encore plus précis en spécifiant la classe ou la fonction de test :

 poetry run pytest <path_to_test_file>::<class_or_function>

Soyez toujours précis sur les instantanés que vous mettez à jour . Ne mettez pas aveuglément à jour une tonne de fichiers d'instantanés juste pour faire réussir vos tests.

S'engage

Tous les commits doivent suivre la spécification Conventional Commits.

Ces messages de validation standardisés sont utilisés pour publier automatiquement les versions à l'aide de semantic-release après la fusion des validations vers main à partir des PR réussies.

Exemple

 feat: add API support for assigning labels to existing samples

Des corps descriptifs et des pieds de page sont requis si nécessaire pour décrire l'impact du commit. Utilisez des puces le cas échéant.

Exigences supplémentaires

1. Écrivez à l'impératif . Par exemple, "fix bug" , et non "fixed bug" ou "fixes bug" .
2. Ne faites pas référence aux problèmes ou aux révisions de code . Par exemple, n'écrivez pas quelque chose comme ceci : "apporter les modifications de style demandées lors de la révision" . Au lieu de cela, "mettez à jour les styles pour améliorer l'accessibilité" .
3. Les commits ne sont pas votre journal personnel . Par exemple, n'écrivez pas quelque chose comme ceci : "le serveur fonctionne à nouveau" ou "oups. J'ai corrigé l'odeur de mon code" .

De Tim Pope : une note sur les messages de validation Git