Page History

...

I made a self-hosted runner that runs in a container 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.

...

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: 

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

Package actions-runner (github.com)

Adding self-hosted runners - GitHub Docs

...

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
   Image Added
   Image Added
2. Run the workflow. (The first x means not completed, then it completes)
   Image Added
   
   
3. The output of the runner is a bit verbose, so its better to look at the results on github actions
   Image Added
   Image Added

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

...