How to auto-approve workflow runs for first-time contributors?

The new security feature that requires maintainers to approve first-time contributors workflow runs is a real problem for me. I’m maintaining a project where many external contributors edit .json files to integrate devices. We have automation in place that checks these .json files for validity and helps unexperienced contributors get it right.

The fact that I now have to manually approve every single workflow run, which often needs to happen multiple times in a single PR, drastically worsens the experience of contributing those files and is frankly wasting my time.

I’d like to automatically test if a given PR only changes these .json files (which do not pose a threat of crypto mining) and then automatically approve them without having to manually intervene. However, I cannot find any documentation on how to detect the necessity for this and how to trigger the builds.

5 Likes

I don’t understand this either. I expected for that change to apply only to PRs that are modifying the actions config file.

It is not enough to check only the Actions config file, as maybe you do pip install -r requirements.txt in there, which could be modified by the PR to point to something malicious.

But still, like 90% of new contributors have no idea what Actions are, and would never have changed its config file. Maybe CI-related files can be marked in some way and if none are changed, then the PR will be auto-approved (unless those files are changed later.) Perhaps using an attribute in .gitattributes?

3 Likes

I mean something as simple as a whitelist with glob support for files would probably cover most use cases. That way the maintainer could specify which files don’t pose the risk of automatically running untrusted code.

Idea:

  1. Add an Action that triggers on an hourly schedule.
  2. That Action enumerates open Pull Requests that don’t yet have a particular label.
  3. For each Pull Request, use maintainer’s Personal Access Token to trigger a build. It’s best if there’s an API to approve the normal build; otherwise, workflow_dispatch is an option.
  4. Add a label to prevent re-triggering.

I really don’t want to be nagging here, but having some kind of roadmap when we can expect changes would be nice.
For just a single PR I had to approve workflow runs at least five times today alone and every time the contributor was waiting to continue…

Note GitHub has stated in their blog post:

This will be the default setting and, as of now, there is no way to opt out of the behavior, but we do have plans to implement a few additional settings to provide more flexibility.