You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reviewing #2147 we noticed a few helper scripts and tests in the repo that are documented for developers (and AI agents) but aren't invoked by any CI workflow. They risk silently rotting because nothing validates them on a regular basis.
Stance: remove them, rather than wiring them into CI.
Reasoning: our CI/CD already runs the relevant tooling on every PR. Writing additional tests to validate that tooling is recursive — tests for tests, tests for tests for tests, and so on. There is no principled place to stop. If the CI/CD breaks, the team will see it immediately on the next PR and fix it. We should draw the line at the per-PR validation layer rather than maintain an orphaned meta-test suite.
Listed in pytest.initestpaths, so a developer who runs plain pytest from the repo root would collect them — but no CI job does that.
.github/workflows/release.yml has a Self-test release-notes checker step that runs pytest ci/tools/tests, but it is commented out.
scripts/run_tests.sh
Recommended in cuda_core/README.md and the per-package AGENTS.md files as the orchestrated way to run tests locally.
No .github/workflows/ job invokes it; CI uses inline pytest calls against specific dirs in test-wheel-linux.yml, test-wheel-windows.yml, and coverage.yml.
Its targets are hardcoded to pathfinder | bindings | core | smoke | all — there is no tools target, so it would not cover ci/tools/tests either.
Proposed action
Delete ci/tools/tests/ and the corresponding pytest.ini entry.
Delete scripts/run_tests.sh and drop / rewrite the README and AGENTS.md guidance that points at it.
While reviewing #2147 we noticed a few helper scripts and tests in the repo that are documented for developers (and AI agents) but aren't invoked by any CI workflow. They risk silently rotting because nothing validates them on a regular basis.
Stance: remove them, rather than wiring them into CI.
Reasoning: our CI/CD already runs the relevant tooling on every PR. Writing additional tests to validate that tooling is recursive — tests for tests, tests for tests for tests, and so on. There is no principled place to stop. If the CI/CD breaks, the team will see it immediately on the next PR and fix it. We should draw the line at the per-PR validation layer rather than maintain an orphaned meta-test suite.
Concrete examples
ci/tools/tests/test_check_release_notes.pyandtest_fetch_ctk_redistrib.pytoday (PR Fix release run lookup for annotated tags #2147 would add a third).pytest.initestpaths, so a developer who runs plainpytestfrom the repo root would collect them — but no CI job does that..github/workflows/release.ymlhas aSelf-test release-notes checkerstep that runspytest ci/tools/tests, but it is commented out.scripts/run_tests.shcuda_core/README.mdand the per-packageAGENTS.mdfiles as the orchestrated way to run tests locally..github/workflows/job invokes it; CI uses inlinepytestcalls against specific dirs intest-wheel-linux.yml,test-wheel-windows.yml, andcoverage.yml.pathfinder | bindings | core | smoke | all— there is notoolstarget, so it would not coverci/tools/testseither.Proposed action
ci/tools/tests/and the correspondingpytest.inientry.scripts/run_tests.shand drop / rewrite the README andAGENTS.mdguidance that points at it.-- Leo's bot