virtool

virtool

virtool เป็นแอปพลิเคชันบนเว็บสำหรับการวินิจฉัยการติดเชื้อของเชื้อโรคโดยใช้การจัดลำดับปริมาณงานสูง

เว็บไซต์: https://www.virtool.ca

เริ่มต้นใช้งาน

ดูเอกสารประกอบ virtool เพื่อเริ่มต้นใช้งาน virtool 4.0.0 เวอร์ชันล่าสุด

เกี่ยวกับเวอร์ชัน

ขณะนี้ virtool กำลังอยู่ระหว่างการเปลี่ยนแปลงครั้งใหญ่ไปเป็นแอปพลิเคชันแบบคลาวด์เนทีฟ ซึ่งหมายความว่า virtool สามารถขยายการทำงานข้ามโฮสต์หลาย ๆ ตัวและทำงานแบบเนทีฟใน Kubernetes และผู้ให้บริการคลาวด์สาธารณะ

สำหรับผู้ใช้และผู้ดูแลระบบปัจจุบัน:

1. ควรใช้ virtool 4.0.0 series ในตอนนี้
2. ซีรีส์ virtool 4.0.0 จะยังคงได้รับข้อบกพร่องและการแก้ไขด้านความปลอดภัยต่อไปในอนาคตอันใกล้
3. virtool 5.0.0 จะประกอบด้วยบริการแบบคอนเทนเนอร์หลายรายการที่ต้องทำงานร่วมกัน จะมีการจัดเตรียมคู่มือการปรับใช้งานและการย้ายข้อมูล

การทดสอบ

ในรูทไดเร็กทอรีต้นทาง:

1. เริ่มบริการสำรองข้อมูลที่จำเป็นใน Docker

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

2. เรียกใช้ชุดทดสอบ:

    poetry run pytest
   

มัลติเพล็กซ์

ชุดทดสอบทำงานร่วมกับ pytest-xdist

 poetry run pytest -n 4

ซึ่งจะใช้กระบวนการ Python หลายกระบวนการเพื่อทำการทดสอบแบบขนาน

สแนปชอต

เราใช้ Syrupy สำหรับการทดสอบสแนปช็อต

สแน็ปช็อตใช้สำหรับการทดสอบที่เราต้องการยืนยันว่าอ็อบเจ็กต์ (เช่น บันทึกฐานข้อมูล, อ็อบเจ็กต์ Pydantic, การตอบสนองของ API) มีรูปร่างและชุดของค่าที่คาดหวัง

หากจำเป็นต้องอัปเดตสแนปชอต:

 poetry run pytest <path_to_test_file> --su

คุณสามารถระบุให้เจาะจงยิ่งขึ้นด้วยการระบุคลาสหรือฟังก์ชันการทดสอบ:

 poetry run pytest <path_to_test_file>::<class_or_function>

ระบุให้เจาะจงเสมอเกี่ยวกับสแนปชอตที่คุณกำลังอัปเดต อย่าสุ่มสี่สุ่มห้าอัปเดตไฟล์สแน็ปช็อตจำนวนมากเพียงเพื่อให้การทดสอบของคุณผ่าน

มุ่งมั่น

การคอมมิตทั้งหมดจะต้องเป็นไปตามข้อกำหนด Conventional Commits

ข้อความคอมมิตที่เป็นมาตรฐานเหล่านี้ใช้เพื่อเผยแพร่รีลีสโดยอัตโนมัติโดยใช้ semantic-release หลังจากที่คอมมิตถูกรวมเข้ากับ main จาก PR ที่ประสบความสำเร็จ

ตัวอย่าง

 feat: add API support for assigning labels to existing samples

จำเป็นต้องมีเนื้อหาและส่วนท้ายที่สื่อความหมายเพื่ออธิบายผลกระทบของการคอมมิต ใช้กระสุนตามความเหมาะสม

ข้อกำหนดเพิ่มเติม

1. เขียนในความจำเป็น . ตัวอย่างเช่น "แก้ไขข้อบกพร่อง" ไม่ใช่ "แก้ไขข้อบกพร่อง" หรือ "แก้ไขข้อบกพร่อง"
2. อย่าอ้างถึงปัญหาหรือการตรวจสอบโค้ด ตัวอย่างเช่น อย่าเขียนสิ่งนี้: "make the style changes request in review" แต่ให้ "อัปเดตสไตล์เพื่อปรับปรุงการเข้าถึง" แทน
3. ความมุ่งมั่นไม่ใช่บันทึกส่วนตัวของคุณ ตัวอย่างเช่น อย่าเขียนอะไรแบบนี้: "got server running again" หรือ "oops.fix my code กลิ่น"

จาก Tim Pope: หมายเหตุเกี่ยวกับข้อความ Git Commit