Making a private Github Runner
- Edward Ned Harvey
- Ronald Canepa
First see Adding Github Actions to a repo
Installation
You will need an on-prem machine and service account to run the runner. Either you or someone from ESCP will need root privilege to configure the service. Please contact escp-ticket@tufts.edu to create these.
Note that Github maintains a matrix of requirements for self-hosted runners. When your OS version goes EOL, your runner will soon follow and may encounter difficulties starting the runner service. You’ll want to ensure that you migrate/upgrade your runner OS ahead of the EOL schedule of your OS. See:About self-hosted runners - GitHub Docs
After the service account is created, someone with root privileges should do this:
If you are not a member of ESCP, document what you’re doing however you document things.
If you are a member of ESCP, document in the node.yaml file:
# See https://tuftswork.atlassian.net/wiki/spaces/ESPTS/pages/499220519/Making+a+private+Github+Runner # Git Runner installed as user 'foobaruser' connected to repo [URL of github repo] # Note: This runner will die after the OS is EOL. For RHEL 8 this is May 31, 2029 # Note: This runner will die after the OS is EOL. For RHEL 9 this is May 31, 2032
In your web browser, browse to your repository.
Go to Settings > Actions > Runners > New Self-Hosted Runner.
It will give you a series of commands to paste into the terminal. Instead of pasting them into the terminal, do this:
Find the line that says "./config.sh --url=..."
Get the URL and the token.
Read the URL to ensure it's a specific repository, not the organization or whatever.
Run this script as root. The script installs the runner, creates the service, and launches the service as the service account. It records the URL of which repository it's working for, in the service account's home directory under "actions-runner-url.txt":
# Optionally, if you need your runner to have any custom label, you may specify --labels= /root/bin/create-gitrunner.sh username GithubRepositoryURL token [--labels=foobarlabel]
Browse back to Actions > Runners, and confirm the new runner appears there, with a green Status, and Idle.
GHA Runner service and systemd+selinux
The OOTB experience when installing the runner in a separate user’s home directory is that the runner will not operate correctly on any system with selinux enabled, such as onprem RHEL9 builds.
For generic notes on selinux, see: SELinux
While the runner installer does attempt to set things properly:
Creating launch runner in /etc/systemd/system/actions.runner.Tufts-Technology-Services-runner-name.service
Run as user: username
Run as uid: nnn
gid: nnn
Relabeled /etc/systemd/system/actions.runner.Tufts-Technology-Services-runner-name.service from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:systemd_unit_file_t:s0
Created symlink /etc/systemd/system/multi-user.target.wants/actions.runner.Tufts-Technology-Services-runner-name.service → /etc/systemd/system/actions.runner.Tufts-Technology-Services-runner-name.service.
Finished. Service is running.this only changes the context of the service itself. The service will try to run a shell script inside the user directory and this will fail:
The fix is to update the selinux context:
Removing a private runner
If you installed a runner as above and need to remove it:
Login as root
Look in ${service_user}/actions-runner-url.txt
Browse to that repository > Settings > Actions > Runners, and force-remove the runner.
Finally
rm ${service_user}/actions-runner-url.txt
If you need separate CI/CD runners on Dev & Prod
Install a runner on dev, and another on prod, using
--labels=developand--labels=mainor whatever. It is customary to match your branch names.Note: you should set up an ssh deploy key, and for the “first run,” you’ll need to clone your repo onto the system into your working-directory manually
Create two separate workflows in your repository, like this:
.github/workflows/autodeploy-develop.yml.github/workflows/autodeploy-main.yml