Yes simtel20 just said that. Hopefully it is what they meant.

Either way I am now responsible for protecting GitHub's CI resources and I don't particularly like it; I'll do it if I must (after all GitHub is generously providing them for free) but I think the post's title is a bit dishonest.

It’s not really in dispute that it’s what they mean. And thus, you aren’t responsible for protecting GitHub’s infra; they’re providing new options for ensuring your own Actions setup isn’t subverted for somebody to mine crypto without your consent.

My objection is simple: I have to protect my CI queue simply because GitHub chose to count PRs from third party against my project's queue. If they simply counted them against the PR author's quota, this abuse wouldn't be happening in the first place. People would run them in discreet repos as they would gain nothing from forking or opening PRs.

Now instead of counting this CI usage in a way more favorable to project maintainers, they give us a way to manually approve runs before they use our CI. That's good, but still a solution to an artificial problem. I think I would have welcomed more openness about why this way of accounting is necessary, instead of this extra work put on me and labeled as a "help" that I never thought I needed.

Running CI on their repo doesn't work when you use self-hosted runners.

Same for when you have secrets defined in the workflow that are necessary for a build.

There are more cases to cover than the ones visible during a knee-jerk reaction.

Obviously I don't consider self-hosted runners to be "GitHub's resources". However those are not widely used by open-source projects and are not mentioned in the blog post, so I don't think that's what the concern is about. I don't think ignoring this minor use-case makes this a "knee-jerk reaction", but name-calling is always appreciated...

I don't see how secrets help with mining cryptocurrency either.

Thanks for your comment I guess?