[antonwolfy]

The test steps wrapped in nick-fields/retry reran the whole suite on every attempt. A real failure cost a second full run (up to ~26 min for the all-integer-dtypes run) before the job went red, and since #3152 a tensor test killed by pytest-timeout reruns the whole tensor suite.

Each pytest command inside a retry step now passes --lf:

• The first attempt has no recorded failures, so it runs everything (--lfnf defaults to all).
• A retry runs only the tests that failed in the previous attempt.
• An attempt killed by the step timeout writes no cache, so the next attempt runs everything again.

Covered: conda-package.yml (Linux and Windows, dpnp and tensor tests), conda-build-test.yml (conda-forge), check-onemath.yaml and the rerun steps of cron-run-tests.yaml. generate_coverage.yaml keeps full reruns, since a partial rerun would replace the coverage data of the full one.

Checked locally with pytest 9.2.0, pytest-xdist 3.8.0 and pytest-timeout, on a package run through --pyargs as in CI, with one test that fails once and one that hangs once:

Attempt	Result
1, no cache (-n 2 --lf --timeout=3 --timeout-method=thread)	all 5 tests ran: 3 passed, 2 failed (one in the worker killed by the timeout)
2, same command	only the 2 failed tests ran, both passed
3, same command	no failures left in the cache, all 5 ran
after a run killed with SIGTERM	no cache written, all 5 ran

This touches the same two tensor test lines of check-onemath.yaml as #3177, so whichever merges second needs a rebase.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?

[github-actions]

Array API standard conformance tests for dpnp=0.22.0dev1=np2py314h8d9cdd5_6 ran successfully.
Passed: 1491
Failed: 0
Skipped: 6

[coveralls]

coverage: 84.397%. remained the same — retry-last-failed-tests into master

[Copilot]

🟡 Changes recommended

Serial pytest attempts can stop on collection errors, allowing a successful --lf retry to pass CI without running the remaining suite; the affected full attempts need --continue-on-collection-errors.

1 open issue

• Run collected tests despite collection errors in serial attempts · New

What changed in this PR

This PR reduces CI retry time by using pytest’s last-failed cache instead of rerunning entire suites, building on the existing tensor-test timeout handling.

Changes:

• Adds --lf to retry-wrapped pytest commands across package, conda-forge, oneMath, and scheduled workflows.
• Documents the intended retry behavior while leaving coverage runs unchanged to preserve full-suite coverage data.

File	Description
.github/​workflows/​cron-run-tests.yaml	Limits Linux and Windows reruns to previously failed tests.
.github/​workflows/​conda-package.yml	Adds last-failed selection to dpnp and tensor retries on Linux and Windows.
.github/​workflows/​conda-build-test.yml	Adds last-failed selection to conda-forge test retries.
.github/​workflows/​check-onemath.yaml	Adds last-failed selection to dpnp and tensor retries for both oneMath configurations.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The targeted CI retry changes have no active review issues.

No open issues 🎉

1 resolved since last review

• Run collected tests despite collection errors in serial attempts

_{Review effort: Balanced}

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/pull/3178/index.html

[ndgrigorian]

@antonwolfy
One concern here is that some tests may only fail as part of a full suite run. It's probably fine either way (if this is consistent, we will notice) but it's something worth considering as unexpected by-product (creation of seemingly "flaky" tests)