Raspberry Pi automated setup

[BlakeFreer]

Our HIL/SIL/Github runner raspberry pi should have an automated setup script, such that given a second pi, we can run a single script to get it to a fully functional state. Not sure if this is a bash script, ansible playbook, or something else.

Since multiple members will be accessing the Pi to run tests, how can we prevent them from installing programs / reconfiguring the pi? This would make the script useless since it doesn't reflect the actual state of the pi. Start by not giving anyone admin privileges.

Can we make a GitHub action that re-runs the script whenever a change is pushed to main? Then if someone wants to install a new program, they edit the script on racecar and make a PR. We could set up an action which triggers a re-install whenever changes to this file are merged to main.

There is an old ansible repo that may help get started. Idk what state it's in or what it does though. https://github.com/macformula/macfe_ansible

Edit: we probably can't achieve a "perfect" one-script install. There may be some additional input necessary, and we don't want to store things like passwords in the repo. The point is these manual steps should be clearly documented alongside the script, and the script should contain as much as possible.

@CameronBeneteau @TylerStAmour What do you think?

[CameronBeneteau]

The choice between a script and Ansible playbook will come down to how complicated the setup gets. If the software stack is simple, a bash script would work. If programs and dependencies are more complex, then Ansible or another framework would be best.

Running tests in containers could make a lot of sense on the Pi (assuming it has enough computing power). Containers would keep our testing environment consistent, no matter who’s running the tests or the Pi's underlying OS. It’s also a good way to keep everything isolated since we won’t need to change much on the Pi itself between tests. We'll also be able to control admin privileges within the containers.

Setting up a GitHub Action to run the script or playbook on the Pi whenever there’s a change to main is trivial (example here). Most of that work would be facilitating the connection between GitHub and the Pi.

How do we imagine people will be testing on the Pi? Manual, automated, or a combination of both?

[BlakeFreer]

I think the best is if all tests are started by a GitHub action when a PR is made, but there should be a more manual front end dispatcher for smaller tests. I think this dispatch would look like "select a commit, project and platform", so the commit needs to exist on origin but doesn't need to be a PR. Varun and the hil team made a hil ui last year so we should get that running first.

[BlakeFreer]

Good to know about that ansible deploy action. I like it more that bash

[TylerStAmour]

Yea I agree on containers for this, this is a textbook case for a custom Dockerfile since you need a reproducible OS image with all your dependencies pre-defined. I'm not super familiar with Github runners but I would assume it would just spin up the container whenever there's a commit, then run the tests within the container.

As for compute, the rpi should be capable enough, docker tends to be lightweight (especially if we'll only ever have 1-2 containers running at any given time)

[TylerStAmour]

As for tests that are started from the HIL-UI, I would guess that we have a second, long-running container (still based on the same dockerfile) that just runs the HIL server. We would still need to maintain some root-level network configurations with that but it's still a better idea than running HIL on root