Systemctl -user enable rviceĪnd you should be in business. Print( 'error: failed to start action-runner')ĭef lifecycle (conn, dom, event, detail, opaque):Ĭonn.domainEventRegister(lifecycle, None)Ĭreate a file ~/.config/systemd/user/rvice: 1ĮxecStart=/home/sean/runner-image/actions-vm-respawn.py Os.system( 'qemu-img snapshot -a restore-me sean-ci-linux-arm64.qcow2') Print( 'error: cannot find action-runner') Print( 'error: failed to connect to the hypervisor')ĭom0 = conn.lookupByName( 'action-runner') 1ĮventLoopThread = threading.Thread(target=virEventLoopNativeRun, name= "libvirtEventLoop") I could not find a way of doing this in shell script, so this is done using the python libvirt api. Now we’re going to create a script which restores the snapshot, starts the VM, and loops when the VM shuts down. Qemu-img snapshot -c restore-me sean-ci-linux-arm64.qcow Once it is shutdown, create a snapshot using: 1 Now your VM should be ready for snapshotting, so shut it down with shutdown -h now. WorkingDirectory=/home/runner/actions-runner 1ĮxecStart=/home/runner/actions-runner/runshutdown.sh Note this could probably be a user service. In the same directory as the runner, create a shell script called runshutdown.sh with the following contents: 1Īlso create a service in /etc/systemd/system/rvice. Do not install the service, we will be creating our own. Now in your VM, download the github runner as instructed by github in your project settings, and configure it and register it using. You can remove a password with passwd -d. I would create a user called runner, with no password and no root password either, so that sudo apt-get install foo. disk /home/sean/runner-image/sean-ci-linux-arm64.qcow2,device=disk,bus=virtio \
Virt-install -n action-runner -memory 16384 -arch aarch64 -vcpus 8 \ Qemu-img create /home/sean/runner-image/sean-ci-linux-arm64.qcow2 -f qcow2 200G So, I think the best way to go about this is to run the runner in a VM, which then shuts itself down after each run, and then is restored from a VM snapshot. The other consideration is that you would like each time that your runner executes some code, it has a clean environment with no residue from the last run. There are a few attack vectors here: someone could create a pull request with some malicious code in it ( there is some mitigation against this), or github itself might be coerced into sending malicious commands to your runner. This software connects to github, and listens to instructions of what jobs to run. In order to run the runner, you run some dotnet code called the GitHub Actions Runner. So, I bought a Traverse Ten64 with the hope of using it as a github actions runner for the Solang Solidity Compiler.
Github actions is great, but it does not offer any arm hardware to run your tests on.