I ran it locally and got 180+ failures 😄. Most of them come from the issue detected in #13649 though. You'll need to backport here the fix you found.

looks like it did not trigger
python -m pytest --showlocals --durations=20 --junitxml=test-data.xml '--cov-config=D:\a\1\s/.coveragerc' --cov sklearn --cov-report= -Werror::DeprecationWarning -Werror::FutureWarning -Werror::numpy.VisibleDeprecationWarning -Wignore:tostring:DeprecationWarning '-Wignore:The distutils:DeprecationWarning' '-Wignore:distutils Version classes are deprecated:DeprecationWarning' -n2 --pyargs sklearn

I do not have issues locally. The problem was introduced in #13649, but likely was not present in another place in the code-base before.

Right, most of the failures comes from #13649. But I do have errors locally on main, from sklearn\ensemble\_hist_gradient_boosting\splitting.pyx. And as I mentionned, looking at the pytest invocation command, it seems that the warning has not be turned into an error here

Which failure do you have exactly so that we can address them?

Imo we first need to make sure we catch them in the CI. Looking at the pytest invoke command #24438 (comment), it seems that the switching into error did not trigger

EDIT: my bad I was looking at the windows job while it's enabled in a linux job.
So it seems that we don't have these errors on linux. Let's try to enable boundscheck in a windows job

as discussed irl, let's try to enable boundscheck in the py38_conda_forge_mkl windows job and see if it's not too long. It means setting SKLEARN_ENABLE_DEBUG_CYTHON_DIRECTIVES : '1' for this job in azure_pipelines.yml.

So, enabling boundschecks didn't trigger any error, but made the run 20min faster 😲

So, enabling boundschecks didn't trigger any error, but made the run 20min faster 😲

There must be something related to shared machines and load balancing. 😄

There is a lot of variability for CI jobs' duration; py38_conda_forge_mkl took:

• 26min on the job triggered by committing 085d6a1
• 45min on the job triggered by committing 5be9d04

I think we can note it generally but ignore this for this PR.