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.

11 Likes

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

1 Like

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?

5 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.

Apparently there is now a Beta API for this:

I’m not sure how it’s meant to be used though.

A little update: I can’t get this API endpoint to work. When I call it, I get an error

Invalid run_id `xxxxzzzzyyy`

however the button in Githubs UI references the same run_id. :man_shrugging:t2:

Honestly, I feel like trying to write an action to solve this is the wrong approach. Instead, GitHub should improve the way they identify when jobs need manual approval. I opened a discussion for that here: "Approve run" is a major pain when managing large OSS ecosystems

You might find GitHub - mheap/automatic-approve-action: Automatically approve workflow runs for new contributors interesting

It automatically approves workflow runs on a schedule assuming that .github/workflows hasn’t been edited. It also provides an option to mark files as dangerous and prevent auto-approving for those PRs

Interesting - I was doing something very similar with a private Github App on the workflow_run.completed event, but ran into the weird invalid run_id error. Kinda hard to test this :confused:

I got one step further. In a Github App (which has the required actions:write permission), I get the above error invalid run_id. By running the same code locally with a personal access token, the approval works just fine.

I wasn’t sure if there would be a race condition when using workflow_run.completed which is why my action runs on a schedule instead

I also got it working for now with a scheduled action, but I’ve modified your approach and used a whitelist for allowed files instead. In case anyone wants to adapt this approach, this workflow

runs this script:

Any easy way to install this at the user/org level, like in a .github repo, to check and auto-approve all the repos periodically?

Heads up for everyone: It is now possible to auto-approve single workflows as a reaction to check_suite.completed events via Github Apps. This was a bug and has now been fixed.

1 Like

Update: There are new options regarding workflow approval.

I don’t think those are a solution either. It is just a choice between slightly less annoying and really fricking annoying.

Is not yet an official solution to this? What if we just want to let all pipelines run for any merge request? We need to allow any contributor (new ones, existing ones, junior or senior) to open a PR and let actions run.

Any updates? I am finding that I need to approve contributors multiple times, for two main reasons:

  • They send a PR to one repository in an organization, I approve them there, and then they send a PR to another repository. I then need to approve them again for each new repository.
  • They push another commit to an already-approved PR. I then need to approve them for each commit.