Run CI conditionally with paths

[vincentmr]

Before submitting

Please complete the following checklist when submitting a PR:

• All new features must include a unit test.
  If you've fixed a bug or added code that should be tested, add a test to the
  tests directory!

• All new functions and code must be clearly commented and documented.
  If you do make documentation changes, make sure that the docs build and
  render correctly by running make docs.

• Ensure that the test suite passes, by running make test.

• Add a new entry to the .github/CHANGELOG.md file, summarizing the
  change, and including a link back to the PR.

• Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

---

Context:
The CI is slow enough to be a real nuisance and productivity killer. This is making devs nervous, especially with freeze week coming.

Description of the Change:
Split tests into CPP and Python tests. CPP tests are run only when changes are made to the CPP source files. Python tests always run.

Test skipping can be seen in action in this PR, targeting the current one.

Benefits:
Run fewer tests which cannot be impacted by changes.
Faster CI runs in Lightning.
Increase GHA runners availability across the organization.

Possible Drawbacks:

Related GitHub Issues:
[sc-61920]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.11%. Comparing base (6260d59) to head (cafc1d6).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #695      +/-   ##
==========================================
+ Coverage   98.39%   99.11%   +0.72%     
==========================================
  Files         150      208      +58     
  Lines       18063    27589    +9526     
==========================================
+ Hits        17773    27346    +9573     
+ Misses        290      243      -47     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mlxd]

Thanks folks. No major concerns from me, but a few questions:

• Will this require us to make the CPP tests as optional, rather than explicit for the CI checks?
• How much better are the CI runs after this? From my experience, the CPP tests were never the bottleneck, but I could be wrong.
• Do we have any any issues with coverage checks, since now we are cutting coverage on the overall ecosystem on a per-PR basis?
• To follow no form the above, do we have issues uploading mutliple coverage files to codecov, or is the number the same as before?

[vincentmr]

Thanks folks. No major concerns from me, but a few questions:

• Will this require us to make the CPP tests as optional, rather than explicit for the CI checks?

I think so, unless we can also make this requirement dependent on the modifications.

• How much better are the CI runs after this? From my experience, the CPP tests were never the bottleneck, but I could be wrong.

This is more true now that we have MCM tests, but GPU tests (and especially MPI tests) are still a bottleneck. This will increase availability so that Python tests can get started faster. This is also a first step to be followed by backend-filtered testing and the use of pytest-split. The latter change will especially benefit from skipping the C++ tests when possible.

• Do we have any any issues with coverage checks, since now we are cutting coverage on the overall ecosystem on a per-PR basis?

Not clear from this PR, but I think nobody really trust CodeCov at this point. For instance, we rarely test MPI code so we have to look at the CodeCov report to really know which lines are meaningfully lacking coverage. Otherwise, I would expect the patch report to be alright.

• To follow no form the above, do we have issues uploading mutliple coverage files to codecov, or is the number the same as before?

Same files as before.

[vincentmr]

I can confirm CodeCov plays nice in 3c40f07.

[mlxd]

No major blocker from me, thanks. I've a few quick comments left, but you can ignore these if no longer relevant.

[mlxd]

Since #664 will likely need an update or two to match this CI change, can that PR go in first?

[vincentmr]

Since #664 will likely need an update or two to match this CI change, can that PR go in first?

Yes, it will be a good test. This might require a few adjustments.

[maliasadi]

Nice work @vincentmr 🥳

[maliasadi]

🪂

[mlxd]

I resolved the merge conflicts locally with the streaming ops. Everything now should adhere to this PR's design