GitHub comments have a length limit, so we can't just dump everything.
The 10k limit is arbitrary, but the assumption is that reviewing the
range-diff is not the sensible thing to do once it becomes a certain
size - reviewing the regular diff and treating the commit as "new" is
easier to do in that case. Thus, truncating should work out fine,
especially when the full range-diff is still available in the runner
log.
This could still end up in with an error, if a PR has multiple commits,
which all hit the limit. Let's get there first, before we try to fix
that hypothetical case, too.
Instead of failing the job, the workflow will now post review comments
as "Request Changes". This makes the feedback more readily visible and
avoids having to merge despite a failing CI job. It is also a
pre-requisite to enable required status checks / required workflows in
the future.
Committers are asked to confirm the differences by explicitly dismissing
the generated review. After dismissal, the related review comment will
automatically be marked as "resolved".
The comments only report warnings and errors. Reviews are automatically
dismissed when they have been addressed by the author and no problems
remain. If problems remain, existing, still pending, review comments
will be updated. If the same problems had already been dismissed
earlier, no new review comment will be created either.
Even though there is only a small window where a commit is not on
staging, but already on staging-next, it is technically valid to
backport commits from staging-next, too.
When cherry-picking without -x or not cherry-picking at all, the
check-cherry-picks job would usually remain green. This is annoying to
deal with for reviewers, because "all green" still needs attention -
have all commits been cherry-picked properly?
If a commit was not cherry-picked correctly, either without -x or not at
all, because it's a genuine commit to begin with, the reviewers
attention is required anyway. Thus we can also let the job fail in this
case.
This makes the job significantly faster when the commit can't be found
on master or staging directly. Before this change, the script would have
had to iterate through 20+ release branches before finding the latest
one. With lazy fetching for git enabled, this would take a few minutes.
Using a `tree:0` filter instead of `blob:none` reduces the checkout time
from over 3 minutes to about 45 seconds. The required trees/blobs will
then be fetched on-demand.
This on-demand fetching creates additional output for `git range-diff`
on stderr, so we hide that. This only happens the first time it's run,
so we don't need to adjust the other calls - which will still return any
real errors, should they happen.
The default is to checkout a contributors fork as "origin", thus the
NixOS/nixpkgs remote is most likely named differently. But not everybody
keeps their fork's main branches up-to-date all the time. Thus the
script would fail locally.
We recently moved the $commits variable out of a "subshell in a
herestring", let's do the same for the list of branches, where errors
would be silently swallowed as well.
Also reformat the expressions slightly, we have enough line-length.
