Speed up ci by removing running CppInterOp unit tests and Valgrind command for CppInterOp

[mcbarton]

No changes to this repo can change the outcome of the tests or Valgrind run of CppInterOp. Best to just do those within the CppInterOp repo, and we should just build CppInterOp in this workflow. This should provide a speedup in the workflow run.

[mcbarton]

@maximusron @vgvassilev any comment on this PR given my comment in the description of the PR?

[mcbarton]

@maximusron @vgvassilev This PR is ready for review.

[aaronj0]

I think we should have the valgrind command, that's essential when we change some API internally we catch some memory issues that could be induced. It is slow but not too slow. I think we can benefit the same impact by reducing some repetitive testing in cppyy or perform valgrind on the make check-cppinterop command to build and run the tests at once.

[mcbarton]

I think we should have the valgrind command, that's essential when we change some API internally we catch some memory issues that could be induced. It is slow but not too slow. I think we can benefit the same impact by reducing some repetitive testing in cppyy or perform valgrind on the make check-cppinterop command to build and run the tests at once.

@maximusron Will you be happy if I keep the Valgrind command, but drop the running of the CppInterOp tests, given the outcome of the tests cannot be effected by changes in this repo?

[mcbarton]

@maximusron can you take another look at this PR?

[aaronj0]

@mcbarton never mind, I think we can drop valgrind on CppInterOp tests altogether here. We only need it on the cppyy tests.

Maybe running the InterOp test suite can be kept in case we pull a broken CppInterOp but we can always catch it on CppInterOp main so should we drop that too?

[mcbarton]

@maximusron I have reverted the PR to not run the Valgrind check in CppInterOp again. Are you happy with the PR now?

[mcbarton]

@maximusron can you merge this PR now that you have approved it?