Consider Self-Hosted Runners for Performance

[timothystewart6]

CI takes a while to run, which is to be expected since we are spinning up VirtualBox VMs on a macOS via GitHub. I've tried running this in kubernetes #136 however Kubernetes isn't the right tool for the job considering that it uses containers and this CI pipeline needs to create and run VMs.

2 options if performance continues to be an issue:

Self Host VMs

• Create a dedicated VM for runners that will pick up the jobs.
• This is the easiest route and takes the least amount of change
• Will just need to configure a VM to handle this

Use K8s but provision Proxmox as a VM provider for Vagrant

• This would allow use to use Kubernetes to coordinate the work and scale up, but then use Proxmox host for the virtual machines that are used and tested.
• This would be the most challenging because we would have to swap the provider from VirtualBox to Proxmox and store secrets etc.
• Some of the work was already done in Self hosted runners #136

[vdovhanych]

If you go the way of using self-hosted runners for GitHub actions that are triggered for pull-request, make sure this option is enabled and set to Require approval for all outside collaborators.
Also, ensure to only allow runs for pull requests that do not change workflow yaml configuration. This could lead to potentially unwanted code execution on the self-hosted runners and someone having access to a machine running in your environment.

[timothystewart6]

If you go the way of using self-hosted runners for GitHub actions that are triggered for pull-request, make sure this option is enabled and set to Require approval for all outside collaborators. Also, ensure to only allow runs for pull requests that do not change workflow yaml configuration. This could lead to potentially unwanted code execution on the self-hosted runners and someone having access to a machine running in your environment.

Thank you! For sure! This is already enabled even prior to testing self-hosted runners! I will also make sure to ignore yaml changes for workflows, good call!

[timothystewart6]

this was fixed by #389