This change allows giving a reason via footer of the commit message for
why this commit is not cherry-picked. This avoids having to "explain"
the automated review comment afterwards - instead, this explanation can
be given immediately when writing that commit.
For example, for an update of `xen` on the stable branch, this could be:
```
xen: 4.19.3-unstable-2025-07-09 -> 4.19.3
[... commit message ...]
Not-cherry-picked-because: unstable is on a different minor version
```
This would then be shown as part of the automated review. The severity
of this will be downgraded from "warning" to "important". We still treat
the review as "changes requested", because it would be very complicated
and noisy to handle two different categories of reviews, some with
requested changes and some with comments only.
An alternative would be to not show this review at all. However, given
that the reviewers expectation on backports should already be "if it's
not a clean backport, the automated review will tell me what to look
at", it seems better to show these and have the committer confirm by
dismissing the review. Otherwise we risk merging actually unreviewed
commits.
The filtered checkout we used before was a nice idea, but only worked
for small numbers of commits in a PR. It would fetch the whole history
initially, but only fetch objects on demand. This turns out to be much
too slow in a PR with 18 commits, regularly hitting the 10 minute
timeout, even when running it locally.
The new approach uses regular checkouts again. In contrast to the old
style, before we switched to the filtered checkout, this only fetches
exactly the commits we need - and all of them at once. This is
significantly faster than both other approaches, and scales much better.
A bigger number of commits doesn't have much of an effect, if any at
all.
This broke when we moved the check-cherry-picks workflow into the bigger
PR workflow. At this time, the "workflow run" became the whole PR
workflow, which includes many more than just 1 job, thus the assumption
in `jobs[0]` doesn't hold anymore.
Most of the checks we do for cherry-picks are dismissable warnings, with
one exception: When a commit hash has been found, but this hash is not
available in any of the pickable branches, we raise this with
severity=error. This should also *block* the merge and not be
dismissable. That's because this is a fixable issue in every case.
Previously, when the diff contained a context line with ```, this would
end the code block and entirely break the markdown rendering.
Now we use the html code blocks provided by `core.summary` and properly
escape the content, so that it never escapes via html tags.
This reduces noise that the cherry-pick reviews produce when formatting
related conflicts had to be resolved. We only do this in the
length-limited review comment, though. All changes, including
whitespace, can still be double-checked in the job log if needed.
This turns the check-cherry-pick script into a github-script based
JavaScript program. This makes it much easier to extend to check reverts
or merge commits later on.
