Page History

...

About Actions Runner Controller - GitHub Docs

Setting up organization wide runner

1. Made personal organization for sandbox 'ad-build-test'
2. Added a runner called runner1 in runner group ad-build-test-runner
3. then i forked the build system repo to ad-build-test
4. and the actions runner was automatically set to the organization runner
5. So i clones the repo on s3df, did a gh repo set-default to set the repo to ad-build-test/BuildSystem
6. then did a gh workflow run to see if it worked and it did.
7. 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
   
   
   
   
8. 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:

1. 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) 
   1. (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

1. 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. 
   1. 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. 
   2. 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.
   3. Choosing the runner for a job - GitHub Docs