Computer Vision System: DevOps and Testing Iteration 2
Objective
Over the next month, we will be taking a detour from the typical development work, and work on improving our DevOps. This encompasses the implementation of proper repository access protocol, the development of documentation, setting up a CI pipeline to run our tests before merge, and the completion of a testing system.
Outcomes
Goal | Requirements |
---|---|
Prevent unauthorized or accidental repository changes. | Implement repository control that enforces branching over forking, no direct pushes to main, and a branch structure that allows for easy testing. |
Make troubleshooting easy | Implement CI with automatic testing to ensure that small bugs are caught. Document our current system more extensively to ensure corrections can be made quickly. |
Complete test coverage | Centralize existing tests into pytest (command maintains its own tests right now). Separate integration and unit tests in the tests folder. Develop a testing system that allows for easy setup of OBS and mock flight data as input, assertion of system outputs, and recording results. Finish writing remaining integration tests, build system tests. |
Requirements
Requirement | Implementation | Assigned to | |
---|---|---|---|
1 | Repository control: No pushes to main | Trivial | Shrinjay |
2 | CI: Identify a CI that fits our needs and secure it. | Â Need to confirm with Dhruv. | Shrinjay |
3 | CI: Centralize all existing unit tests in PyTest (mostly command module) | Move the QR scanner tests out of the class and make sure that the tests point to the test image. Move the command module tests out, convert unittest to pytest, and make sure all our unit tests can be run by just the command pytest. If tests don’t pass, note them and we’ll make tickets for it. | Gary |
4 | CI: Setup CI to run tests on every github PR, identify if we want to run unit and integration or just unit, and seperate. | Whenever a github PR is opened, the CI should run all our unit tests and give us a test report. | Wenfei |
5 | Test Rig: Make OBS easier to setup (documentation, OBS scripting?) | We think it is possible to get a source setup programatically. We should be able to pass an image path, a video path, and a flag specifying if this is an image or a video and the script should setup an OBS stream that can be captured by OpenCV. | Xierumeng |
6 | Test Rig: Develop mock flight data solution | We will implement random data generation that creates fake POGI JSON files and puts them into a pipeline out. This can then be treated like a mock command module. | Kevin |
7 | Test Rig: Develop test class for all tests to subclass off, refactor existing tests. | Create 3 base classes, one that sets up OBS only, one that sets up flight data only, and one that sets up both. Setup means that the OBS script is run (assume it exists for now, don’t write code for it, assume you’re calling a fucntion called run_obs()), OpenCV has a capture running, and and the mock command runner is called (assume its called mock_command_data()) and its output is assigned to a pipeline. Now pipeline with mock data and a capture object should be available depending on base class. | Lucas |
8 | Completion: Complete ground side telemetry | Complete and resolve issues with ground side telemetry and write integration tests so we have a reliable data transfer system. | Andrew |
9 | Documentation | Start by using python’s documentation library to generate docs from our current docstrings. Modify the generated documentation/clean up docstrings and add diagrams to compile our final documentation. | Shrinjay (Tentative) |
10 | Documentation: Diagrams | Draw updated diagrams for the new CV system. Diagrams should detail data flow. | Shrinjay |
11 | Documentation: README | How to setup, how to run, expected outputs, for each program. Move the code standards into a seperate md document. | Shrinjay |