Proposal: Action to verify if the PR lands cleanly on active release lines

[RafaelGSS]

Currently, it's painful for the releaser and for the contributor to land commits on non-current release lines due to conflicts. It's an annoying task to ask for a backport, and it's also bad for the contributor to create a backport PR after a month or two and land this feature in 2/3 months.

My suggestion is to have an action that, when the author-ready flag is placed, it will attempt to cherry-pick this commit on active release lines and inform the user when it fails.

It will make the life of releasers easier, and the contributor could create a backport without having to wait 2 months~

cc: @nodejs/releasers

[aduh95]

I was thinking about that as I was working on the next v22.x release, another pain point is that the current labelling system gives too little info.
From a backporter perspective, I am under the impression that it would be worth to always try to cherry-pick PRs that did not land cleanly on a previous session (and just skip it if it still doesn't land cleanly), while it's almost never worth trying to cherry-pick PRs that e.g. land cleanly but make some test fail.

For example, I've just landed the node config backport, which unblocked the backport of several other PRs, but it was kinda tricky to find which ones.

when the author-ready flag is placed, it will attempt to cherry-pick this commit on active release lines and inform the user when it fails.
and the contributor could create a backport without having to wait 2 months~

How do you foresee this working? LTS release lines are always weeks behind main, most likely the "cherry-pickability" of a commit before it has even landed on main would not be very interesting, I'm not sure what the contributor could do with that info 🤔

[joyeecheung]

My suggestion is to have an action that, when the author-ready flag is placed, it will attempt to cherry-pick this commit on active release lines and inform the user when it fails.

I think trying PRs individually on release branches may incur a lot more false positives if the release branches isn't kept up with the main branch fast enough - from my experience doing backports, if PR B is touching code already touched by PR A, then the automation needs to know that it must cherry-pick PR A first before trying PR B, otherwise it's going to encounter conflicts needlessly (this was what I tried to reduce some churn for with git node backport but I didn't put enough work to it so the algorithm was very naive and only look at file overlaps for dependents, not more specific code range overlaps). Sometimes the entire train can get blocked once a particular PR is having a conflict, even though the conflicts of that particular PR might be superficial (e.g. some mass stylistic refactoring), cherry-picking subsequent PRs without that one would cause a lot of problems, but once the superficial conflicts are resolved for that PR the train can move forward smoothly. In that case if the automation isn't aware of the bottleneck, it may send false alarms to all the later PRs in the train, even though it's only the backport of the bottleneck PR that's actionable.

[aduh95]

In #56143, I've raised the idea of using "staging-staging" branches where commits that land on main would be attempted to be cherry-picked right away so the automation can tell us¹ if a commit doesn't land cleanly or if the linter is not happy.

Footnotes

1. either by opening an issue, or by adding a comment to the PR, depending what level of noise we're happy with. ↩