mergify: Automatic approve and run on merge commit

[mxinden]

Summary

We have to manually allow CI to run on external pull requests via the "Approve and Run" button.

When an external pull request is approved (as in review not CI button), has the send-it label and is part of the merge queue, then mergify will automatically merge latest master when the pull request gets outdated.

Unfortunately that master merge requires another click on the Approve and Run button to trigger CI, thus pull requests are not automatically merged.

Example would be #3234.

@thomaseizinger any ideas off the top of you head?

Would you like to work on fixing this bug?

No

[jxs]

We have to manually allow CI to run on external pull requests via the "Approve and Run" button.

This is only for first time contributors right?

Btw, an orthogonal issue also happens that sometimes Github asks for the CI to be approved to run for members of the project considering them to be first time contributors, see #3196

[thomaseizinger]

You should be able to change the GitHub settings to something more useful: https://matklad.github.io/2022/10/24/actions-permissions.html

[thomaseizinger]

I always forget that we have https://github.com/libp2p/github-mgmt, let's see if we can specify this there.

[thomaseizinger]

I couldn't find anything in https://registry.terraform.io/providers/integrations/github/latest/docs unfortunately. @galargh Can you confirm whether or not we can set this setting via terraform?

In any case, I think we should change it to the setting linked in the blogpost above!

[galargh]

Unfortunately, the Actions settings for repos cannot be managed through API (at least they couldn't the last time I checked) and thus terraform/github-mgmt cannot control them either.

Here's the relevant piece of documentation on approving workflow runs from public forks.

The available options are:

1. Require approval for first-time contributors who are new to GitHub
2. Require approval for first-time contributors
3. Require approval for all outside collaborators

In this repo, we're currently on option 2. but I think we should be fine with 1. which is more permissive. I didn't do a full audit but I don't think we have any workflows here that can be triggered from a PR that come with costly side effects.

Let me know if you want me to adjust the settings.

[thomaseizinger]

Let me know if you want me to adjust the settings.

Given that @mxinden opened this issue, I think it is safe to say that he will be okay with moving to option (1) so we can fix this issue. @jxs what about you? I am certainly in favor.

We can always revert if an issue arises so I think it is safe to say that you can go ahead and change this @galargh. Thank you :)

[galargh]

Done 👍

[thomaseizinger]

I think we can close this then!

[mxinden]

Very much appreciate you pushing this through @thomaseizinger and @galargh 🙏

Btw, an orthogonal issue also happens that sometimes Github asks for the CI to be approved to run for members of the project considering them to be first time contributors, see #3196

Oh, this is the first time I see this. @jxs please speak up in case you see this happening again.