We currently consider test-only changes as jstest only changes, which is a subset of what is actually test-only. There isn't a more accurate method in determining what is test-only. When server-release is removed from approver, we need an automated way to enforce what is and isn't test-only.

AC:

• design a criteria for a given PR to determine what is test-only
  • ex: if all code files changed include the word "test"
  • See discussion: https://mongodb.slack.com/archives/C0V79S1PY/p1751054760527579
  • Answer: Test-only files should be expanded to include:
    • ** _test.* *
    • ** _tests.* *
    • ** _bm.* *
• Enhance the Release Readiness check introduced in STAR-7699, and make an exception for PRs that have test-only changes.
• Update the Release Readiness field indicators on BACKPORTS to better encapsulate that test-only changes do not have to abbide by timing req policy:
  • Blocked by Upstream Release = 'Unreleased Upstream', 'Risk of Regression'. This will inform the author that not everything is 'blocked'
  • Timing Requirement Met = 'Ready to Stage' or 'Ready to Merge'