The advantage of having someone else operate it evaporates when it is neutralized by complexity and scale. The failure modes of our own setup are much, much easier to deal with.
I figure this must be an easily solved problem, but not sure how everyone else is doing it.
It's moving the problem but at the end of the day the repo owner has to look over and choose to accept or reject the PR.
I seem to remember that a CI run for a PR takes the workflow file from the HEAD of the branch, rather than master. But I'd have to check.
So even if you have a workflow that requires a manual trigger, I can just fork, and create a PR that updates that trigger to be `pull_request` and the workflow will run as soon as I create the PR. I don't need the PR to be accepted before I can start running arbitrary code on your self-hosted runner.
Or am I missing something?
Perhaps it would be more clear to imagine two files, a workflow file describing the CI steps and a permission file describing what can trigger the CI.
The CI will use the permission file from the last trusted commit (which would also be the last commit that the CI was run on) but uses the workflow file of the current commit.
In your case you create a PR that updates both the workflow and permissions file. The CI sees that the previous trusted commit requires that I, the repo owner has to manually submit unknown PRs to the CI. Seeing that your PR is malicious, I don't submit the PR to the CI.
Now that I've layed it out explicitly I realise that the non intuitiveness comes from using git to track CI configuration in the same repo.
Asking out of curiosity, not as a gotcha