github-actions: validate linux-next cherry-picks

[nirmoy]

Summary

• Accept (cherry picked from commit <sha> linux-next) as an upstream reference.
• Validate linux-next cherry-picks against the patch URL from their Link:
  trailer instead of resolving the SHA. linux-next is rebuilt daily and its
  objects are not reachable from the origin/linux ref patchscan fetches, so
  SHA resolution cannot succeed in CI.
• Prefer the patch.msgid.link trailer, which maintainers append at apply time,
  over earlier Link: trailers pointing at reports or discussions.
• Report a b4 fetch failure, a missing Link: trailer, and a patch-ID mismatch
  as distinct errors rather than folding them together.
• Add regression coverage for the trailer form, URL-based validation, Link:
  selection, fetch failure, and absent b4.

This fixes the validation errors reported on NVIDIA/NV-Kernels#539.

Validation

• python3 .github/scripts/test_validate_pr.py -v — 22 tests passed.
• Ran the updated validator against PR [26.04_linux-nvidia-bos] Backport Vera I3C v7 support #539 — all 17 commits passed lint; the
  intentionally adjusted SETAASA patch is reported as annotated. (Run against
  the pre-restructure revision; [26.04_linux-nvidia-bos] Backport Vera I3C v7 support #539 stays red until this merges, since
  patchscan.yml pulls validate-pr from origin/github-actions.)

[jamieNguyenNVIDIA]

A handful of Claude findings:

The regex widening in get_cherry_pick_sha() is the right fix for the reported
symptom, and it does clear the R6 lint errors on #539. The concern is that the
errors move rather than disappear, and the new Link:-based rescue never runs in
the CI environment it targets.

1. The rescue path is unreachable under patchscan.yml

build_digest() resolves the trailer SHA before it can reach the new logic:

        if upstream is None:
            errors.append("E: {} (\"{}\"): cannot resolve upstream SHA {}".format(...))
            rows.append(dict(..., patch_id='ERROR', subject='ERROR', sob='ERROR',
                             error=True))
            continue                       # validate-pr:814
        ...
        else:
            linux_next_url = get_linux_next_patch_url(commit.message)   # :826

patchscan.yml checks out NVIDIA/NV-Kernels and fetches only origin linux.
NV-Kernels carries no linux-next mirror branch, and the linux-next SHAs are not
in the repository at all, so neither repo.commit(src_sha) nor the
repo.git.fetch(upstream_remote, src_sha) fallback can succeed:

$ git fetch --depth=1 https://github.com/NVIDIA/NV-Kernels.git \
      bbaf8733b84846897d2d3b997ce650dd2d2539a4
fatal: remote error: upload-pack: not our ref bbaf8733b848...

# control, mainline SHA from the same PR:
$ git fetch --depth=1 https://github.com/NVIDIA/NV-Kernels.git \
      2543fbb21642f740288e3c292cab03cd611f35a4
 * branch  2543fbb21642... -> FETCH_HEAD

Running this branch's validate-pr against a commit carrying the real trailer
and the real Link:, in a repo whose only remote is NVIDIA/NV-Kernels:

Checking 1 commits...

Cherry-pick digest:
E: 3a6916d6731d ("i3c: master: Add support for devices usi"): cannot resolve upstream SHA bbaf8733b848
│ 3a6916d6731d │ bbaf8733b848 │ ERROR │ ERROR │ ERROR │

Lint: all checks passed.
exit 1

So on #539 the eleven R6 lint errors are replaced by eleven digest errors, and
steps.validate.outputs.result is still error. The difference from the local
run in the PR description is most likely a linux-next remote in the
workstation clone; CI has no equivalent.

Underneath the remote-configuration issue there is a durability one: linux-next
is rebuilt daily, so a linux-next SHA is not a stable reference. bbaf8733 is
reachable only from linux-next/master and does not correspond to the mainline
commit for that patch.

Suggested direction: branch on the linux-next marker before SHA resolution
and treat it like the existing (backported from <url>) case at lines 771-790 —
skip repo.commit() and is_equivalent_replay() entirely, validate the diff
against the Link: patch via b4, and use describe_sob_chain_backport() for the
SoB column. That path already works without a resolvable upstream object, and it
sidesteps the SHA-instability problem as well.

If there is a companion change to patchscan.yml that fetches linux-next, this
analysis does not apply — worth saying so explicitly.

2. Two things to fold into that rework

Both live inside the code that would move, so they are part of the same change
rather than separate requests.

get_linux_next_patch_url() returns the first allowlisted Link:, but the
patch link is conventionally last. Maintainers append
Link: https://patch.msgid.link/<msgid> at apply time; earlier Link: trailers
are author-supplied references to reports or discussions. The www.mipi.org
link in a05cce2f8cec happens to be filtered by the host allowlist, but a
lore.kernel.org discussion link is not:

Link: https://lore.kernel.org/all/CACwKKmCZdiZDoFuYm6LZhQ=...@mail.gmail.com/   <- selected
Signed-off-by: Youngjae Kwon <yjkwon0026@snu.ac.kr>
Link: https://patch.msgid.link/20260802015801.2426818-1-...                     <- wanted

Across the last 3000 linux-next commits, 1169 carry a patch.msgid.link
trailer and 32 of those (2.7%) have a lore.kernel.org Link: earlier in the
message. Whether each one then fails depends on what b4 finds in the referenced
thread, but the selection is wrong regardless. Iterating in reverse, or
preferring patch.msgid.link over the other allowlisted hosts, covers it.

A b4 fetch failure is reported as a patch-ID mismatch. Lines 831-839 pass
only on match/noted; fetch-err, no-diff, no-match and non-lore all
fall into the same error, which reads patch-ID mismatch with upstream ... and
gives no hint that b4 could not retrieve the patch. The sibling path documents
fetch-err as "b4 failed (network/tool issue) → warning, not error"
(line 688). Fail-closed here is defensible, but a transient lore outage
currently flips a PR red with a message that points at the wrong thing.

3. The new test does not exercise the new logic

test_accepts_linux_next_cherry_pick builds an exact cherry-pick, so the
patch-IDs match, is_equivalent_replay() short-circuits, and the else branch
never runs. Confirmed by instrumenting get_linux_next_patch_url() with a
marker-file write and running the test: zero hits. The test covers the
get_cherry_pick_sha() regex widening only.

Untested as a result: get_linux_next_patch_url() (Link: selection, host
allowlist, the rstrip(').,')), the patch.msgid.link → --single-message
translation in _b4_fetch_series(), and the url_status → pid_status
mapping. The first is pure string handling and needs no network, so it is the
cheapest to cover — though args = parser.parse_args() at module scope
currently blocks importing the script for unit tests, so that would need a
main() guard first.

The rest checks out: b4 am --single-message exists and is inherited by am
via cmd_retrieval_common_opts(), b4>=0.13 is pinned in requirements.txt,
and patchscan's looser from commit ([a-fA-F0-9]+) regex already matches the
linux-next form, so no companion change is needed there. All 18 tests pass
locally.

[jamieNguyenNVIDIA]

Another pass with Claude on the follow-up commit.

Restructure verified end-to-end — the earlier repro now exits 0 and validates by
URL without touching the SHA. The Link: preference change picks the right URL
on the real lore-discussion-first case, and the new tests cover the previously
untested logic (UNRESOLVED_SHA reproduces the CI condition directly, and the
fake b4 asserts both the selected msgid and --single-message). 20/20 pass.

Three small leftovers:

1. The previous linux_next_url fallback at 880-893 is now unreachable: the new
   branch at 792 continues at 823, so linux_next_url is always None there
   (confirmed by instrumenting that if — zero hits across the suite while the
   enclosing else is reached 13 times). Worth deleting, along with the
   elif diff_status == 'non-lore' at 810-811, which can't fire either since
   get_linux_next_patch_url() only returns allowlisted URLs and
   check_backport_diff() re-checks against the same allowlist.

2. _b4_fetch_series() documents "Returns None on b4 failure" but only handles a
   non-zero exit — subprocess.TimeoutExpired and FileNotFoundError propagate
   as tracebacks (seen directly with b4 off PATH). Since fetch-err now has a
   tailored message, except (OSError, subprocess.SubprocessError): return None
   finishes that off. Matters more now that every linux-next commit goes through
   b4, where previously only (backported from <url>) commits did.

3. A linux-next pick with no allowlisted Link: still reports
   cannot resolve upstream SHA, which points at the SHA rather than at the fix.
   (backported from <url>) handles that case correctly today (verified — same
   patch, noted / exit 0). A special-cased message when the linux-next
   marker is present but no usable Link: was found would save the next person
   the same debugging round.

None of these block.

[nirmoy]

Thanks @jamieNguyenNVIDIA , valid findings. Updated the PR.

[jamieNguyenNVIDIA]

Acked-by: Jamie Nguyen <jamien@nvidia.com>

[ianm-nv]

LGTM!
Acked-by: Ian May <ianm@nvidia.com>