Making a private Github Runner

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.

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.

• Now you have a choice. You can do the Manual process below, or the Scripted process.

• Manual:

  • If you just follow GitHub’s instructions copying & pasting the commands they give you, there are a few issues. (1) When someone logs into the linux machine and looks in the runner directory, there is no way to know what repo it’s connected to. (2) When you login to github and look at the repo, there is no way to know what host or username the runner is running under. (3) At the end of github’s installation process, the runner is running, but it’s not configured to start as a service on the machine.

  • The instructions here help you manually install the runner, while addressing all those issues.

  • On the linux host, become the service user.

    # become root sudo su - # become the service user su - exampleuser1

  • Copy/paste the commands from github, up to and including extracting the tarball. Don’t run the config line yet.

  • When you run the config line, it will prompt you interactively:

    • Runner group: (just press enter to leave it blank)

    • Name of the runner: Enter something of the form hostname_username so you can easily identify where the runner runs just by looking at the runner in github

    • Labels: In most cases just press enter, but if you want any extra labels, type them here

    • Work folder: (just press enter)

  • Don’t run the last line that github provides you, run.sh. That would launch it once and it would not persist a reboot. Instead, continue as follows:

  • Since there is no record on the linux host, which github repo this runner is connected to, go to the service user’s home dir, and create a text file

    cd # Edit the following. Put the URL of the github repo echo url > actions-runner-url.txt

  • Logout as the service user. Become root.

  • See notes below about selinux GHA Runner service and systemd+selinux. After fixing the selinux context come back here.

  • Edit the following. Substitute something appropriate for ${user_home_dir} and $service_user

    # Do this as root # Substitute something appropriate for ${user_home_dir} and $service_user cd ${user_home_dir}/actions-runner ./svc.sh install $service_user service_name=$(./svc.sh status | grep '^/etc/.*service$' | head -n 1 | sed 's/.*\///') systemctl enable --now $service_name

• Scripted:

  • 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:

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

  cd ${service_user}/actions-runner ./svc.sh uninstall rm -rf ${service_user}/actions-runner

• 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=develop and --labels=main or 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

    name: autodeploy-develop on: push: branches: - develop jobs: autodeploy: runs-on: [ self-hosted, develop ] steps: - working-directory: /path/to/repository run: git pull

  • .github/workflows/autodeploy-main.yml

    name: autodeploy-main on: push: branches: - main jobs: autodeploy: runs-on: [ self-hosted, main ] steps: - working-directory: /path/to/repository run: git pull