[AIROCMLIR-1146][CI] Always report required checks on external/llvm-project-only PRs

[bogdan-petkovic]

Motivation

The GitHub Actions workflow never runs on LLVM upstream merges, nor on PRs confined to external/llvm-project/**. Its required checks then sit as "Expected - waiting for status to be reported" and the PR cannot merge without an admin bypass. A skipped workflow is not a skipped job: the former never creates a check run, so branch protection has nothing to observe.

Two causes. GitHub evaluates on: <event>: paths: filters against only the first 300 files of a diff, so an LLVM subtree pull fills every slot with external/llvm-project/ entries and no run is created at all — which is why #2427 produced zero runs despite changing 12 files this workflow owns.

Technical Details

The path set moves out of the trigger filters into a single relevant-changes job that the three existing jobs key their steps off. They now always run and always report, but do no work when nothing relevant changed. The path set is unchanged, so which PRs get checked does not change, only how that decision is computed, and the required check names are untouched, so no branch protection changes are needed. The filter is dropped from the push trigger too, since the 300-file cap applies there as well and the path set should live in one place.

Detection needs no checkout. For a pull request it fetches GitHub's merge preview ref with --depth=2 --filter=tree:0 and diffs it against its first parent; for a push it diffs the event's before/after range.

So every branch that cannot prove there is nothing in scope answers true, and the guards test != 'false' rather than == 'true': a failed or missing detection runs the real checks instead of passing them.

--ignore-external is passed to premerge-checks.py when the diff touches external/llvm-project, mirroring the ignoreExternalLinting parameter Jenkins sets by hand. Without it the first upstream merge to reach this workflow would lint ~18k vendored files held to upstream style.

Also added: permissions: contents: read, a concurrency group matching the claude_auto_review* convention, and timeout-minutes on the detection job.

Test Plan

The exact run: block was extracted from the workflow and executed under GitHub's own shell invocation, bash --noprofile --norc -e -o pipefail, with GITHUB_OUTPUT redirected to a file — so the tested code is the code that ships, with errexit active. It was exercised against real PRs and a real push range covering both outcomes, all four event types, and the failure paths. Since this PR touches .github/workflows/ it always resolves to relevant=true, so the external-only outcome was observed on a live run by temporarily forcing the result and reverting immediately after.

Test Result

case	input	result
PR #2427	18,690 files, 18,678 vendored, 12 relevant	relevant=true ignore_external=true
PR #2336	1 file under external/llvm-project/	relevant=false ignore_external=true
push range	develop~3..develop	relevant=true ignore_external=true
workflow_dispatch	no diff to inspect	relevant=true ignore_external=true
closed / nonexistent PR	merge ref absent	relevant=true (fail-safe)

Every case exits 0 under -e. Live runs on this PR:

scenario	Detect	C/C++ premerge	Python lint	Python tests
relevant=true	4s	8m39s	4m46s	4m49s
relevant=false (forced, then reverted)	2s	2m25s	30s	22s

In the forced run all three jobs reported SUCCESS under their required check names, confirming that a job whose steps are all guarded off still reports success rather than a skipped conclusion — the behaviour an external-only PR depends on, now measured rather than assumed.

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[rocmlir-pr-reviewer]

⚠️ This PR modifies the Claude-review CI security perimeter

The following files in this PR control whether and how the
claude-review workflow protects its LLM Gateway secrets at
runtime (see .github/workflows/CLAUDE_AUTO_REVIEW.md):

• .github/workflows/ci.yml

Before applying the claude-review label on this PR, please:

1. Audit the diff in these paths line-by-line. A malicious or
   accidental change could disable the --allowedTools
   restriction, the overlay step, the sanitizer, or the
   review/post job split -- any of which would expose the
   secrets in env to the PR-modified workflow.
2. If the changes are legitimate and you want a Claude review,
   do NOT apply the claude-review label. Instead, run via
   Actions → Claude Auto Review → Run workflow and enter
   this PR's number. The dispatch path runs from the trusted,
   code-owner-approved version of the workflow on
   develop, so a malicious PR-side
   modification cannot affect the run.

(This banner is automated. The modifies-ci-paths label
will be removed automatically if a future push removes the
perimeter modifications. The Layer-3 in-workflow guard will
additionally fail the claude-review label-triggered run
on this PR if the label is applied while perimeter changes
are present.)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2443      +/-   ##
===========================================
+ Coverage    82.57%   83.60%   +1.04%     
===========================================
  Files          120      121       +1     
  Lines        42852    43182     +330     
  Branches      7110     7181      +71     
===========================================
+ Hits         35381    36101     +720     
+ Misses        4815     4499     -316     
+ Partials      2656     2582      -74     

Flag	Coverage Δ
gfx120x	83.48% <ø> (+0.96%)	⬆️
gfx950	83.46% <ø> (+1.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 33 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.