Re-attempt platform automerge

[straub]

Tell us more.

Hey folks,

I've encountered a similar issue as #25699, so I'd like to open the feature request mentioned there.

My use case is on GitHub, attempting to use their Merge Queue feature with Renovate. I have a dependency file that is very prone to merge conflicts and has many updates available (a Jenkins plugins.txt). I'm finding the GitHub Merge Queue actually works slightly less smoothly than Renovate's native automerge, since when the Merge Queue ejects a PR that's developed merge conflicts during the process, it requires human intervention to make it back in, even after Renovate has rebased and resolved the conflict.

My understanding is that the root cause is that Renovate only attempts to add the PR to the merge queue when it's created, and not on future updates, via this code:

renovate/lib/modules/platform/github/index.ts

Line 1520 in bde9512

await tryPrAutomerge(number, node_id, platformOptions);

I also understand that infinite loops are possible in some configurations where checks are different in CI between the main branch and PRs, so having PRs re-added to the Merge Queue on updates by default might not be wise and could potentially waste CI resources forever. This is not a concern in my use case, as I have the same checks on the main branch as in PRs.

I don't think I exactly need Renovate to re-enable GitHub's automerge after any push, but at least after Renovate's own pushes would be very helpful.

If you folks would be open to a new opt-in flag to enable another call to tryPrAutomerge() during updatePr(), I'd be happy to try my hand at implementing it!

Please let me know if you have any other questions, concerns, or guidance. And as always, thank you so much for all your hard work!

[rarkins]

Please go ahead! It would be handy to have such PRs added back to the queue as long as it doesn't result in any loops

[straub]

limit it to whenever Renovate rebases

It looks to me like a simple way to accomplish this might be to implement a refreshPr method in the github platform and do a tryPrAutomerge() there. Does that sound reasonable to you? If so, I'll get to work on a PR!

[rarkins]

I'm not sure about the refreshPr naming specifically but probably it does need a new, optional function to be added to GitHub

[straub]

Sure, very open to suggestions! Trying to re-orient myself in Renovate's code, I went looking for how updatePr() might know a rebase just happened, and found refreshPr() instead. It looked like a good extension point in about the right place already:

renovate/lib/workers/repository/update/branch/index.ts

Lines 574 to 576 in 4fc7554

	if (branchPr && platform.refreshPr) {
	await platform.refreshPr(branchPr.number);
	}

[straub]

I think I could rationalize the refreshPr naming as "we're refreshing the PR's GitHub automerge / merge queue status after rebasing", if that's convincing at all 😄

[straub]

I've submitted an initial PR for this: #26567

[straub]

I believe #26567 resolves this discussion, released in v37.255.0. Thanks!