Running CI or PR tests on contributor PRs?

[JakeQZ]

I noticed that when a contributor submits a PR, the CI/PR checks are not run until a maintainer allows them to be run.

This means that a contributor potentially has an extra round of code changes to make (because they have to wait for a maintainer to initiate the CI checks - e.g. #485), and can be offputting. (I have seen several times contributors give up on their PRs after being asked to make changes, so would prefer not to discourage contributions any more than necessary.)

So I wondered if there's any reason why automatic running of the CI/PR checks are disabled on contributor branches/forks.

Other relevant things:

• We should add a contributor guide, like at https://github.com/MyIntervals/emogrifier/blob/main/.github/CONTRIBUTING.md
  • This would include info on running the CI Composer scripts locally
  • The bit at the end of the README could then direct to this
• We should add a Composer script to run the unit tests
  • I might do this now, as I can check it works on Windows

[oliverklee]

About the other relevant things: Yes, please! ❤️

[oliverklee]

This is why PRs by first-time contributors to a project need the okay of a maintainer to run the CI jobs:
https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/

TL;DR: People were using PRs to open-source projects for cryptomining.

[JakeQZ]

About the other relevant things: Yes, please! ❤️

Added #488 and #489.

https://github.blog/2021-04-22-github-actions-update-helping-maintainers-combat-bad-actors/

This seems to me like using a sledgehammer to crack a nut, after first trying with broken nutcrackers.

Surely the 'reputation' of a project should never be impacted by what whoever does with a fork of it. Surely any GitHub actions in that fork should be run against the quota for the user account that created the fork. And surely it's just as easily possible to create a new project with a GitHub action that does cryptomining.

Surely any GitHub actions in that fork should be run against the quota for the user account that created the fork.

They obviously got this wrong in the first place, which led to the problem of innocent accounts and repositories being blocked. They've now fixed that, it seems. But also blocking forks from running the actions is total overkill IMO.

Also, after I'd approved the workflow run, I had to re-approve it when post-review changes were made, which also seems unnecessary to me.

@oliverklee, I have shared related concerns about GitHub via email in the past.

Complaining about it won't achieve anything. Closing.

[JakeQZ]

One of these is pull requests from forks being used by bad actors to run mining code on upstream repositories.

That's where the problem is. The actions should run on the downstream forked, not the upstream. Have they fixed that? (Bob the Builder can ;))

[oliverklee]

Depending on the configuration, the actions can actually also run on the downstream fork (at least for some project to which I've contributed), though that's not visible in the PR.

Sometimes, the actions need to access some secretes (API keys etc.), so they'll only run with the full result on the upstream repository.