3 ms·

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 minin

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.

remram 5y ago
"accounts may be blocked"... if they mean "CI may wait in queue" then it was a very poor choice of words
- akerl_ 5y ago
  > 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.
  - remram 5y ago
    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.
    - akerl_ 5y ago
      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.
      - remram 5y ago
        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.
        hashhar 5y ago
        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.
        remram 5y ago
        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?

remram 5y ago

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

akerl_ 5y ago
> 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.
- remram 5y ago
  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.
  - akerl_ 5y ago
    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.
    - remram 5y ago
      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.
      - hashhar 5y ago
        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.
        remram 5y ago
        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?