...
- 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
{"serverDuration": 58, "requestCorrelationId": "1e34ddda1ccc231d"}