Github actions runner

This page is documentation of the github actions runner we plan to use

Possible setup #1 - GitHub enterprise

Possible setup #2 - Self hosted runner

I made a self-hosted runner that runs on s3df on a repository named BuildSystem slaclab/BuildSystem: BuildSystem for EED software development and configuration management (github.com). The actions themselves doesn't do much, since this is a proof of concept.

But also communicates with github, and posts build results there under the 'Action' tab.

1. Here is setup
     

1. And then run, and manually trigger the workflow using Github CLI (I installed github CLI on my goenv)
   
   Result on github repo 'Actions'
   

To think about: Should we use github CLI to be the base tool for our CLI? It seems to have features we need like triggering a workflow manually. But it also allows you to create your own commands. Maybe we can make a simplified wrapper around the CLI - And make only certain options visible to the end user?

Resources:

Adding self-hosted runners - GitHub Docs

If go this route:

1. Add the self-hosted runner at the organization level (So every repo just needs to enable their self-hosted runner to the 'buildsystem' so they're able to communicate to the buildsystem).
2. (optional) configure the self-hosted runner as a service

Possible setup #2.1 - Self hosted runner in a container

1. This is the same as #2 except it runs in an apptainer container
   
   
2. Run the workflow. (The first x means not completed, then it completes)
   
   
   
3. The output of the runner is a bit verbose, so its better to look at the results on github actions
   
   

This works too but i am not sure if is scalable, because in the definition file (build_system_runner.def), i cd into the actions-runner/ directory which is already preconfigured for 1 runner. If multiple runners are made, then may have to configure all of them.

Resources: 

Provide runner as a Docker Image · Issue #367 · actions/runner (github.com)

Package actions-runner (github.com)

Possible setup #3 - Self hosted runner with jobs in containers

May be the optimal route if we host the build system on our own hardware (or virtual). 

This solves 2 problems:

1. No bottleneck on the self hosted runner since the runner will just spin up containers to do the jobs, not the runner itself. 
2. Not having the runner rely on github resources that can potentially cost money if overused. Also not having a self-hosted runner for each project, we can host the runner organization wide (like propose #2) and have every project enable their actions runner to 'build-system'.

Running jobs in a container - GitHub Docs

Creating a Docker container action - GitHub Docs

Possible setup #4 - Self hosted runner autoscaling (kubernetes)

May also be optimal route, but need to look into it. Surface level: Runners are created/deleted based off usage. This route involves kubernetes infrastructure.

Autoscaling with self-hosted runners - GitHub Docs

About Actions Runner Controller - GitHub Docs