Run scipy tests as part of the Github Action CI#4935
Conversation
|
Hi, @lesteve, thanks! I may not have the full context of how intensive the tests can be for CI, as others do. Still, I think responding to the |
|
Thanks @lesteve! I really needed this :)
I prefer this one.
I think it is okay to do that. We don't build all packages in GHA, as we already build everything in CricleCI. But adding scipy seems reasonable to me. The situation will change if we unvendor recipes later anyways (#4918). |
|
OK thanks for your inputs, in b2ef91a I now build scipy in the "core" build. I will look at adding a trigger based on commit message next. |
|
Thanks @lesteve! |
|
Summary:
|
|
I'll go ahead and merge this since the firefox test is a flake and pre-commit is hopefully fixed on main by #4938. |
|
Thanks @lesteve! |
|
Yeah pre-commit.ci is green, I figured that the issue with codespell was actually to use small letters in the ignore file, oh well ... At least the last commit is a good additional sanity check to show that when the |
|
Scipy tests pass so I'll merge it. Thanks again @lesteve! |
|
Great, thanks! Quite happy that I finally took the time to contribute this and that this can be used by others! Except a few quirks, it was almost 100% fun 😉 |
|
Thanks so much for your help with scipy! It makes my life a lot easier and I think we are getting better outcomes. |
Description
It would make a lot of sense to have Pyodide developers be able to run Scipy tests rather than asking me to do it manually based on https://github.com/lesteve/scipy-tests-pyodide when needed. Last time this happened is for the f2c fork PR #4920 (comment). You could imagine that the Scipy 1.13 PR #4719 would benefit from this as well as potentially many other PRs.
I am testing this on my fork, see GH logs from my PR branch in particular this GH log where the scipy tests ran without error.
This is a bit of a draft PR as there are a few questions:
[full-scipy](in scikit-learn we use them for a few things, like forcing a full doc-build, running the Pyodide CI in a PR, etc ...)Side-comment: I am using
-m 'not slow'because otherwise I saw some weird memory issue towards the end of Scipy tests, see this build log where some tests can not allocate enough memory for the numpy arrays. Locally I get a Pyodide fatal error at 97% of the test, not sure whether this is related.One of the error
Checklists
I am guessing none of the checklist items apply here so I ticked all of them ...