GitHub CI

If you don’t want to run the runner as service then you can follow the steps posted at Adding self-hosted runners - GitHub Docs to create a self-hosted runner in ExCL.

Setup Runner as a service in ExCL

If you do want to register the runner as a service, the easiest way is to use systemd user services. To set this up follow the steps below.

Create a user systemd config which is unique to a single system.

Notes:

• If you are trying this on a system which doesn’t already have a /scratch folder the command will fail. Please send an email to to create a folder for local storage.

• If you setting up a second runner, the ln command will fail if the link already exists. Ensure that the link is a valid link pointing to scratch before continuing with these instructions.

Create a folder to store the GitHub Runner.

The steps are similar to that posted at with some changes. You will need to create one folder per machine and per repo so I recommend the following structure.

~/github-runners/<node>-<repo>

Download and Configure the Runner.

Once you create this directory and enter it, you will then download and configure the runner. The steps are reproduce below, but you should follow the instructions from the “add new self-hosted runner” page after clicking on “New self-hosted runner”.

Patch the Runner Folder for use as a User Systemd Service.

Apply this patch to modify the directory to use user systemd modules.

Enable linger for your user

Use this command to enable linger for your user.

This allows your user-level systemd services to run when you are not logged into the system and auto-start when the system is rebooted.

Note: Use loginctl disable-linger to remove linger and ls /var/lib/systemd/linger to view the users with linger set.

See for more information.

Use the svc.sh script to install and manage the runner service.

After this patch is applied the svc.sh script works as documented in . However you don’t need to specify a username since it now defaults to the current user. The commands are reproduced below.

Install service

Start service and check status.

Note: The above install adds the service to auto start on reboot. If you want to disable or enable this auto starting of the service run.

or

To stop the service run

To uninstall the service run

Creating a secure, human-in-the-loop CI pipeline for public repos

GitHub Actions the use of self-hosted runners for public repos. However, if you want to use an ExCL self-hosted runner for a public repo, you can use the following steps to create a secure CI pipeline that is triggered by an authorized user in a PR comment. This will prevent unauthorized users from running arbitrary code (e.g. attacks) automatically on ExCL systems from any PRs.

We follow the resulting workflow yaml file in the JACC.jl as an example that can be reused across repos.

1. Select authorized users: those who can trigger the pipeline and store it in a in your repo using the following format: CI_GPU_ACTORS=;user1;user2;user3; and store another secret TOKENIZER=; to be used as a delimiter (it can be any character). Users should have a strong password and 2FA enabled.

2. Trigger on issue_comment: this is the event that triggers the CI pipeline. The types: [created] ensures that the pipeline is triggered only when a new comment is made and not when an existing comment is edited.