The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
PyTorch’s Cross-Repository CI Relay (CRCR) can send upstream changes to downstream projects’ continuous-integration systems and route their results back to PyTorch reviewers. It does not decide which tests an accelerator backend should run or what a passing result means. Torch Spyre’s integration shows how downstream maintainers can make those decisions explicit: select relevant tests, adapt them without editing upstream files, and make CI results reproducible and understandable.
What CRCR does—and what downstream maintainers still own
PyTorch and out-of-tree accelerator backends evolve in separate repositories. A change in pytorch/pytorch can affect a backend even though its code is maintained elsewhere. CRCR connects those repositories: an upstream event can dispatch a downstream workflow, and the downstream result can be surfaced in PyTorch’s CI CRCR HUD. PyTorch’s overview explains the relay’s role at Introducing Cross-Repository CI Relay.
The relay coordinates dispatch and reporting; it cannot determine whether a test is meaningful on a particular device, whether a failure is expected, or whether a green result is sufficient evidence. Those remain downstream responsibilities. For a backend, the test surface has three moving parts: backend code, PyTorch core, and PyTorch’s test suite. Testing a newly dispatched upstream revision while holding the backend baseline steady can help identify regressions associated with the upstream change.
The September 30, 2026 PyTorch article by Mehant Kammakomati, Jewel K M, Anubhav Jana, and Padmanabha Venkatagiri Seshadri describes Torch Spyre’s approach in From Upstream Changes to Downstream Confidence: Inside Torch Spyre’s Integration with PyTorch CRCR. The project is an out-of-tree backend; its project materials describe a PrivateUse1/OpenReg project with an Inductor backend in the Torch Spyre repository and Torch Spyre documentation.
#1 Best Overall
How an upstream change reaches downstream CI
CRCR integration begins with repository wiring. The PyTorch article describes an allowlist entry, a workflow that listens for repository_dispatch, and a callback action that returns status. Integration can range from receiving notifications to reporting results and participating in upstream pull-request validation.
Dispatch details that affect workflow design
The dispatch payload can include the upstream commit SHA, pull-request number, action, base branch, and labels. Workflows should use the SHA supplied by the event so that a downstream run tests the exact upstream revision that triggered it, rather than a moving branch tip.
Merge handling can be less straightforward: the article notes that PyTorchBot’s “Merged” label may arrive after a dispatch or may be absent for manual merges. A workflow that depends on detecting a merge may need to poll for the label or use a fallback heuristic. These mechanics are implementation details and can change.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
CRCR does not dispatch nightly runs, so nightly validation needs separate scheduling. Release testing can be triggered manually; the article says the HUD did not then provide a dedicated release-results view.
Integration-level status needs a scope caveat
The Torch Spyre article reports that the project reached CRCR’s L2 integration. PyTorch’s main CI Integration documentation, however, says CRCR currently supports L1 (Silent) integration only. These statements describe different scopes or documentation states, and the sources do not resolve the difference. Treat the L2 statement as the Torch Spyre article’s project-specific report, not as a universal description of CRCR’s current availability.
Which PyTorch tests are meaningful on your hardware?
PyTorch’s test suite is too broad to treat every case as equally useful for every backend. Torch Spyre’s described selection process moves from broad scope to concrete cases, then checks those decisions against real hardware.
Rank #3
1. Set the high-level scope
Start with the backend’s extension points and maintainer preferences: which capabilities are implemented, which areas are priorities, and what types of changes downstream CI should cover. This defines the relevant territory before looking at individual tests.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
2. Build a repository index
The team describes a repository memory index containing symbols, files, summaries, and per-test embeddings. That index makes it possible to search the shortlisted test surface and relate test cases to relevant code and concepts.
3. Select, bucket, and explain cases
At the case level, selection can consider backend code, documentation, and metadata such as supported operators. The selected tests are assigned to outcome buckets with written rationale. The generated configuration is the reviewable record of those choices: it makes the intended coverage and exceptions visible to maintainers rather than leaving them implicit in CI logic.
Rank #4
4. Refine with hardware results
Static analysis cannot reveal every runtime failure or numerical difference. Running selected cases on real hardware exposes such issues and can inform later selection and expectation changes. When a backend adds support for an operator, the team says the corresponding config can admit tests that had been waiting on that capability.
For upgrades, the authors describe refreshing the repository memory and reassessing new or modified tests rather than reprocessing the entire suite. In their PyTorch 2.13-to-2.14 upgrade example, they report evaluating about 4,000 changed tests instead of tens of thousands. That is the authors’ example, not an independently verified or general performance benchmark.
How to adapt CUDA-written tests without patching upstream
Torch Spyre’s approach uses declarative configuration to reuse upstream tests while keeping the upstream test tree unchanged. The framework targets generic PrivateUse1 devices and supplies defaults for tests without a specific override.
| Configuration | Purpose |
|---|---|
| Defaults | Define the backend’s baseline handling for tests without an individual rule. |
mandatory_success |
Mark cases expected to pass as a requirement. |
xfail |
Record an expected failure. |
xfail_strict |
Use strict expected-failure handling, so outcomes that contradict the expectation are not silently treated as ordinary success. |
skip |
Exclude a case from execution. |
| Parameter-level edits | Adjust an individual parameterized test—for example, exclude unsupported dtypes without discarding the entire test. |
| Capability declarations | Declare supported operations and dtypes so selection can reflect backend capabilities. |
The article says decorators such as @ops, @modules, and @dtypes are patched at collection time to create pytest marks. This lets the test framework apply backend-specific selection and expectations at collection time instead of forking upstream test files. The distinction matters: upstream tests remain the shared source, while downstream configuration records the backend’s current capabilities and expected outcomes.
Which dispatches deserve a build—and what makes a result trustworthy?
A dispatched run is useful only if its trigger is relevant and its result can be tied to a known code revision. The Torch Spyre article describes several practices for improving signal and operational reliability.
- Filter for meaningful events. Avoid building on dispatches that do not represent changes the backend intends to validate.
- Resolve the exact upstream SHA. Record and test the revision named in the payload, not whichever commit happens to be newest when the job starts.
- Split and balance the suite. Group work by feature, divide it to fit duration limits, and balance individual tests across splits.
- Build once, test many. Reuse PyTorch and backend wheel artifacts across test splits rather than rebuilding separately in each one.
- Isolate parallel jobs. Keep concurrent work independent so one job’s state does not compromise another’s result.
- Use retries selectively. Retries can help distinguish transient infrastructure problems from persistent test failures, but should not obscure genuine regressions.
- Make failures interpretable. Preserve detailed logs and classify failures so maintainers can distinguish infrastructure issues from backend or upstream regressions.
There is also a callback constraint for matrix workflows: a matched in_progress and completed callback pair must originate from the same job. A matrix design should account for that relationship so results are reported consistently.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhat “green” is allowed to mean
A passing downstream status is meaningful only in relation to the tests selected, the outcomes declared, and the upstream revision actually exercised. If a case is skipped, expected to fail, or omitted because a capability is unsupported, those decisions need to be visible in the configuration. Likewise, a green status should not be read as proof that every PyTorch test passes on the backend: it reports the result of the defined downstream run.
That is why test selection and result reporting belong together. CRCR can carry a result back to reviewers, but downstream maintainers define the coverage and expectations that make the result interpretable. In Torch Spyre’s account, the configuration—not an opaque agent decision—is the reviewable record of those choices.
