No way to prevent bad PR's title and body changes

[AlekSi]

Hello. We are developing our software in a public repository where everyone contributes with PRs from forks. Currently, we use GitHub's auto-merge that allows us to specify exact commit title and body for squash&merge. Only trusted people can enable auto-merge, and they should check that the commit body title and body are good. External contributors can't enable and disable auto-merge; changing PR's title or body after auto-merge is enabled does not affect auto-merge's commit parameters. All that allows us to have good people-checked commits that are then used to generate a changelog, etc.

Currently, we use Mergify with actions: update to update other ready PRs when one PR is merged into the main branch. Of course, that updates all ready PRs at once, wasting CI resources. Naturally, we looked into Mergify's merge queue. It allows specifying the commit title and body using templates that could reference PR's title and body. Unfortunately, it seems there is no way to prevent accidental (or intentional) bad changes in PR parameters after it is put into a queue. We almost could prevent it with a required GitHub Actions check and re-request review on pull_request.edited event. But there is a race condition when a new Actions job is not running yet.

Is my analysis accurate? Is there a way to solve that problem?

I think it could be solved by combining GitHub's auto-merge and Mergify. A new merge_method value (that could be called nothing, wait, auto-merge, or something like that) that would just wait for GitHub to auto-merge that PR before updating the next one in the queue would do the job. Would you consider implementing something like that?

(I discussed that with a few people in separate discussions. This topic is created to gather everything in the same place.)

[jd]

Hi @AlekSi !

Your analysis is correct, indeed.

I imagine we could have a different merge_method that would rely on Mergify waiting on an external system doing the merge. That's not our short-term roadmap, so it might be worth implementing something else in the meantime.

I think your idea of triggering a GHA when a pull request is edited is a good pick. There's indeed a race condition, though that race condition would exist in anyway as everything is event based and asynchronous, inside GitHub and with Mergify anyhow (the size of the race being probably different then). And it's likely going to work in 99.99% of the cases.