> It's really not obvious to me why you'd ever punish one account/repository for the actions of another account in another repository...

Well, from the blog post, that's one of the changes they outlined:

> Specifically, if we determine an Actions run to be abusive or against our terms, our enforcement will be directed at the account hosting the fork and not the account associated with the upstream repository

My guess is the reputation was a naive initial implementation, designed to prevent against someone opening a Github account, creating a mining action and running it. They probably just didn't consider these scenarios carefully when first applying reputation to pull requests, and this blog posts is them fixing it.

It's really for their benefit rather than maintainers. The actions abuse was apparently a major capacity issue.

I think you are reading "blocked" as in "account suspended", while I think the article means that other users' jobs are blocked - meaning waiting - as the mining code is running instead of completing in a short time as you'd normally expect.

"accounts may be blocked"... if they mean "CI may wait in queue" then it was a very poor choice of words

> This obviously has a negative impact on repository owners whose legitimate pull requests and accounts may be blocked as a result of this activity.

They’re saying that the malicious actions block builds for legit users.

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?

Ooph, yeah I can see this turning into a big headache for large community repos. People are going to submit a first pull and then start opening issues like "Why hasn't pull request #123 been approved yet?, "Please approve my pull #456", etc. within minutes and hours.

...maaaayyyyybe.

But on the other hand, it makes it less likely that crypto miners will bother opening up junk PRs against your repo. So you save some time there.

People already do that regardless of this new feature.