Not exactly a brainstorm but nothing really checks this box.
TLDR: if access to ziglangs runners needs to be restricted (and it probably should) the only way to do it is by setting the runner group workflows to Selected Workflows and adding ziglang/zig/.github/workflow/ci.yaml@master to the list. Failing that anyone can run arbitrary code on the runners.
I was today years old when I realized running an action on a repo forked from another repo would run your action on the upstream runners.
I was refactoring the CI scripts to remove the requirement to edit them between every build and also make them double as build/install scripts for newcomers to make onboarding easier. Flipped on actions to make sure I didn’t have an odd typo breaking everything and noticed only one ran, which is odd because I have several runners just sitting idle.
Killed the action, searched through all the settings I could think of but found nothing that would throttle jobs, and ran it again with the same result. Then I noticed Jacob had a branch redoing ci scripts in zig (which is fine but then I guess I have to own the onboarding scripts I wanted now) and he has a check in front of each job requiring the action to originate from the ziglang/zig repo. And that’s where it clicked.
Quickly did a bunch of searching through github docs, and yup, public repositories share their runners with every forked repo, and by default there are no restrictions on what workflows can use them. So if Jacob, if you’re here, the check won’t do anything because anyone can write a ci to run anything on their fork of zig.
I’d like to meet the person that decided that was an ok behavior for self-hosted runners, or just runners in general.