This page is documentation of the github actions runner we plan to use
Possible setup #1 - GitHub enterprise
...
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
Setting up organization wide runner
- Made personal organization for sandbox 'ad-build-test'
- Added a runner called runner1 in runner group ad-build-test-runner
- then i forked the build system repo to ad-build-test
- and the actions runner was automatically set to the organization runner
- So i clones the repo on s3df, did a gh repo set-default to set the repo to ad-build-test/BuildSystem
- then did a gh workflow run to see if it worked and it did.
- So i then created another runner called runner2, but ran the same commands, the only difference was i changed the actions-runner folder to actions-runner2
Image Added
Image Added - So I ran 2 different workflows (content doesn't matter) And since workflow 'CI' occupied runner1, running workflow 'CI-2' didn't queue on runner1, the job moved to next available runner, since runner2.
This proves that we can have multiple runners to satisfy users requests
Drawback:
- Since repos on slaclab are public, we would have to enable the 'Allow public repositories' on the runner groups. (Which may have a security risk if non-slac users fork the repo and trigger the runners)
- (Update, we can allow public repos, just as long as the runners are only allowed to run within the organization, which is allowed for enterprise - Managing access to self-hosted runners using groups - GitHub Enterprise Cloud Docs) To solve this, in the organization's 'General actions permissions', set the policy to 'Allow <organization_name> actions, and select non-ad-build-test, actions and reusable workflows'. So only people within the organization can access the runners. And can include other actions like default github ones
Workflow Access
- In the github organization settings, we can specify 'runner groups'. Where each group can take jobs from any workflow, or certain workflows chosen by administrator.
- This could be useful if we want 'nightly builds' to be their own group, so there will always be runners available in other runner groups.
- You could also add labels to the runners, and then on the workflow job yaml you can specify the label to determine which runner to run on.
- Choosing the runner for a job - GitHub Docs