Self-hosted runners are also useful when debugging weird behaviour in a GitHub Action.<p>I do it by spinning up a VM on my local pc, then running the GitHub Actions software in the VM.<p>This gives a fully working GitHub Actions runner which I can ssh into directly and muck around with to investigate and get things working.<p>It's also easy to ensure only the right jobs end up on my runner.<p>The installer for the GitHub Actions runner asks for optional tag names to use, so I add "jc" (my initials) to the tags.<p>Then I add a matching "jc" to the "runs-on" clause in the workflow in my fork or PR:<p><pre><code> runs-on: [self-hosted, linux, x64, jc]
</code></pre>
With that, the GitHub Actions for that workflow only run on my local VM.<p>Works pretty well. :)<p>---<p>Official docs for the labelling bit: <a href="https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow#using-custom-labels-to-route-jobs" rel="nofollow">https://docs.github.com/en/actions/hosting-your-own-runners/...</a>
Having recently set up a Gitlab self-hosted runner, the process seems far, far simpler - it's a case of running a Docker image on your system (or installing a binary/package), registering your runner through Gitlab settings and you're finished.<p>It manages running things in other Docker containers for you (or on one of many other runner options) and it worked without any modifications to my workflows. Very pleased with it.
I have a setup on a Pi for deploying progscrape.com that has a systemd task to boot a new runner in a container. I really need to turn it into a bare-metal deployment script so I can recover from an SD card crash.<p>Basically this service:<p><pre><code> [Unit]
Description=%N Container
After=docker.service
Requires=docker.service
[Service]
TimeoutSec=3600
Restart=always
WorkingDirectory=/srv/progscrape/progscrape-deploy/github-runners
ExecStartPre=-/usr/bin/docker compose -f %N.yml -p %N stop
ExecStartPre=-/usr/bin/docker compose -f %N.yml -p %N pull
ExecStart=/usr/bin/docker compose -f %N.yml -p %N up
ExecStopPost=-/usr/bin/docker compose -f %N.yml -p %N rm -f
[Install]
WantedBy=multi-user.target
</code></pre>
Boots this docker compose definition:<p><pre><code> services:
github-docker-runner:
image: myoung34/github-runner:latest
restart: "no"
environment:
RUNNER_NAME: progscrape-docker-compose
RUNNER_WORKDIR: /tmp/work
EPHEMERAL: 1
LABELS: management,linux,ARM64
DISABLE_AUTO_UPDATE: 1
env_file:
- github-runner.env
configs:
- github-runner-start
entrypoint: /bin/sh
command: /github-runner-start
security_opt:
# needed on SELinux systems to allow docker container to manage other docker containers
- label:disable
volumes:
- '/var/run/docker.sock:/var/run/docker.sock'
configs:
github-runner-start:
file: runner-start.sh</code></pre>
I am kind of surprised that the Action runner isn’t just some sort of Container or VM manager like Drone?<p>The runs actually occur on your real OS? That seems strange and dangerous.
We're running a lot of CI on our custom runners. The fact that it runs in the OS context is a bit meh. If someone has a good resource on setting up docker on a RPi for a custom runner, please throw it my way.