Fix HUD grouped view showing all-grey cells for domain repos (#8276)

## Summary

The **grouped** view of the HUD renders every group cell **grey**
(`AllNull`, the `~` symbol) for non-`pytorch/pytorch` repos — e.g.
https://hud.pytorch.org/hud/pytorch/vision/main and
`pytorch/executorch`. The ungrouped view and `pytorch/pytorch` grouped
view are unaffected.

## Root cause

`HudGroupedCell` computes a group's status from `effectiveJobs`. When
the **"Hide non-viable/strict blocking"** preference is on (it
**defaults to `true`**), `effectiveJobs = jobs.filter((job) =>
isJobViableStrictBlocking(...))`.

`VIABLE_STRICT_BLOCKING_JOBS` is only defined for `pytorch/pytorch`, so
`isJobViableStrictBlocking` returns `false` for **every** job in any
other repo → `effectiveJobs` becomes empty. The status computation then
hits:

```ts
} else if (noStatusJobs.length === effectiveJobs.length) {  // 0 === 0 → true
  conclusion = GroupedJobStatus.AllNull;                    // → grey "~"
}
```

so every grouped cell is grey regardless of the real job conclusions.

The **column-visibility** use of this preference is already guarded with
`isPyTorchPyTorchRepo` (`pages/hud/.../[[...page]].tsx`), but the
**cell-status** use in `GroupJobConclusion.tsx` was not — that asymmetry
is the bug. (The preference checkbox is also disabled off
`pytorch/pytorch`, so users can't work around it.)

## Fix

Guard the cell-level filter the same way as the column-level filter, so
it's a no-op off `pytorch/pytorch`:

```ts
const isPyTorchPyTorchRepo = repoOwner === "pytorch" && repoName === "pytorch";
const effectiveJobs =
  hideNonViableStrict && isPyTorchPyTorchRepo
    ? jobs.filter((job) => isJobViableStrictBlocking(job.name, repoOwner, repoName))
    : jobs;
```

This restores green/red grouped cells for `vision`, `executorch`,
`audio`, etc., and leaves `pytorch/pytorch` behavior unchanged.

## Test plan

- Added `isJobViableStrictBlocking` unit tests: `pytorch/pytorch`
job-name matches (pull/trunk/lint/…, plus mem_leak exclusion) and
domain-repo always-`false` behavior that this fix relies on. Expected
values verified against the matching logic.
- Manual: on `hud/pytorch/vision/main` in grouped view, cells now show
green/red instead of all-grey; `pytorch/pytorch` grouped view unchanged.

AI assistance (Claude) was used for this change.

Co-authored-by: pytorchbot <soumith+bot@pytorch.org>

Author: atalman

torchci/components/job/GroupJobConclusion.tsx

@@ -165,11 +165,22 @@ export default function HudGroupedCell({
   // When hiding non-viable-strict, restrict the group's status calculation
   // (and tooltip contents) to viable/strict-blocking jobs only — otherwise a
   // non-viable-strict failure would still light up a kept group column.
-  const effectiveJobs = hideNonViableStrict
-    ? jobs.filter((job) =>
-        isJobViableStrictBlocking(job.name, repoOwner, repoName)
-      )
-    : jobs;
+  //
+  // The viable/strict-blocking concept only exists for pytorch/pytorch, so this
+  // filter must be ignored for every other repo. Without this guard, on a
+  // domain repo (e.g. pytorch/vision, pytorch/executorch) the filter removes
+  // *every* job from the group, `effectiveJobs` becomes empty, and the status
+  // computation below falls into `noStatusJobs.length === effectiveJobs.length`
+  // (0 === 0) => AllNull => every grouped cell renders grey. This mirrors the
+  // column-visibility guard in the HUD page (`isPyTorchPyTorchRepo`).
+  const isPyTorchPyTorchRepo =
+    repoOwner === "pytorch" && repoName === "pytorch";
+  const effectiveJobs =
+    hideNonViableStrict && isPyTorchPyTorchRepo
+      ? jobs.filter((job) =>
+          isJobViableStrictBlocking(job.name, repoOwner, repoName)
+        )
+      : jobs;
 
   // Check if this group contains autorevert signals
   const isAutorevertSignal = rowData

torchci/test/jobClassifierUtil.test.ts

@@ -1,4 +1,7 @@
-import { getNameWithoutOSDC } from "../lib/JobClassifierUtil";
+import {
+  getNameWithoutOSDC,
+  isJobViableStrictBlocking,
+} from "../lib/JobClassifierUtil";
 
 describe("getNameWithoutOSDC", () => {
   test.each([
@@ -47,3 +50,31 @@ describe("getNameWithoutOSDC", () => {
     expect(getNameWithoutOSDC(input)).toBe(expected);
   });
 });
+
+describe("isJobViableStrictBlocking", () => {
+  // pytorch/pytorch defines viable/strict-blocking job patterns.
+  test.each([
+    ["pull / linux-jammy-py3.9-gcc11 / test", true],
+    ["trunk / macos-py3-arm64 / build", true],
+    ["Lint / lintrunner", true],
+    ["some-random-job", false],
+    [", mem_leak check", false],
+  ])("pytorch/pytorch %j -> %s", (jobName, expected) => {
+    expect(isJobViableStrictBlocking(jobName, "pytorch", "pytorch")).toBe(
+      expected
+    );
+  });
+
+  // Domain repos have no viable/strict-blocking definitions, so every job must
+  // be reported as non-blocking. Regression guard for the HUD grouped-view bug
+  // where applying this filter on a domain repo emptied every group and turned
+  // all grouped cells grey (AllNull).
+  test.each([
+    ["pytorch", "vision", "pull / linux / test"],
+    ["pytorch", "vision", "Build Linux Wheels"],
+    ["pytorch", "executorch", "trunk / lint"],
+    ["pytorch", "audio", "unit-test / linux"],
+  ])("%s/%s job %j -> false", (repoOwner, repoName, jobName) => {
+    expect(isJobViableStrictBlocking(jobName, repoOwner, repoName)).toBe(false);
+  });
+});