Closed mcbarton closed 1 month ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 75.45%. Comparing base (
f93e7b6
) to head (5d91d19
). Report is 20 commits behind head on main.
@vgvassilev I changed the python version to 3.11 like the other repos. This has some jobs failing that aren't in the other repos, but this appears to be due to differences in the ci. I will investigate but suggest merging for now.
@mcbarton there is a PR #268 that is fixing the recent regressions on the CI, which mostly stems from Valgrind preventing the build CppInterOp step from not progressing further, reverting the python version to 3.10 and CUDA. I would suggest that we hold on landing this PR for now
@mcbarton there is a PR #268 that is fixing the recent regressions on the CI, which mostly stems from Valgrind preventing the build CppInterOp step from not progressing further, reverting the python version to 3.10 and CUDA. I would suggest that we hold on landing this PR for now
@maximusron In your PR can you change it to python 3.11 and fix the Valgrind error after the CppInterOp build? We can then change the Valgrind check in the other repos to also not unconditionally return true (See https://github.com/compiler-research/cppyy-backend/blob/c4854922de0afa96e9acd3f8f147a292d2e72776/.github/workflows/ci.yml#L586C1-L588C11 as an example). I will then close this PR.
@maximusron Relating to CUDA and CppInterOp. Do you think this may be useful for the workflow in future in CppInterOp? https://github.com/github/roadmap/issues/961 .
@mcbarton there is a PR #268 that is fixing the recent regressions on the CI, which mostly stems from Valgrind preventing the build CppInterOp step from not progressing further, reverting the python version to 3.10 and CUDA. I would suggest that we hold on landing this PR for now
@maximusron In your PR can you change it to python 3.11 and fix the Valgrind error after the CppInterOp build? We can then change the Valgrind check in the other repos to also not unconditionally return true (See https://github.com/compiler-research/cppyy-backend/blob/c4854922de0afa96e9acd3f8f147a292d2e72776/.github/workflows/ci.yml#L586C1-L588C11 as an example). I will then close this PR.
The reason I am suggesting 3.11 instead of 3.10 is that returing to 3.10 returns an error when the workflow reruns with regards to the pip version, which we have no ability to stop appearing. The goal is to have no errors appear when the workflow runs.
fix the Valgrind error after the CppInterOp build?
yep this is done in the PR, will take a look at windows next. Regarding the python versions, that can be tried at the end since we have the option to revert safely.
Relating to CUDA and CppInterOp. Do you think this may be useful for the workflow in future in CppInterOp? https://github.com/github/roadmap/issues/961 .
If the runner has an Nvidia GPU then the rest is something we can set up in theory, installing the nvidia-drivers package and use the rpm for CUDA sdk installaion. Maybe this can be opened as an issue as a future upgrade for the CI
@vgvassilev After the changes by @maximusron I can now update to a newer version of python, removing the pip version warning from runs of the ci, without it breaking the ci. I believe this should be merged along with https://github.com/compiler-research/CPyCppyy/pull/52 https://github.com/compiler-research/cppyy-backend/pull/101 https://github.com/compiler-research/cppyy/pull/80
rerunning jobs on this PR to see if python 3.11 works over the recent PR's merged
@maximusron are you able to merge this PR, alongside the other PRs mentioned above, now your rerun is complete?
@mcbarton @vgvassilev the run was successfull, this PR is good to go
This should allow the pip version error to not appear, while not having the issue introduced in the last PR. Will know for sure once ci has run on this PR.