Testing CI #35
Description
Problem
There are several disparate ways to "test" the stack. Between the cocotb+Verilator stack and the growing number of hardware targets, it will rapidly become unwieldy to validate changes.
Proposed Solution
We can use GitHub actions to run tests on a staging machine. My security mitigation plan is to use a "sacrificial lamb" system, whose entire configuration is held in Ansible playbooks in the event it becomes corrupted, and to have that system in a DMZ (only able to access the wider internet, not the local network). Most importantly, repository policy that requires maintainer approval for outside contributor PR commits to be run through this CI should be implemented.
Hurdles
Unfortunately, for HWIL tests, this involves using machines with real development boards hooked up. That rules out the typical GitHub workflow that involves fairly generic Linux containers running in the cloud for those tests. However, self-hosted runners for public repositories is very discouraged, hence the security mitigations mentioned above. Additionally, this somewhat depends on #34 but can be worked in tandem.
Expected API Impacts
None.