...
- 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)
- 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": 59, "requestCorrelationId": "74334568cf99b8f9"}
