Revert "Increase timeouts" for CI #5828
Conversation
This reverts commit ade493a.
DanielNoord
added
the
Maintenance
Pierre-Sassoulas
left a comment
Pierre-Sassoulas
left a comment
There was a problem hiding this comment.
What if the issues is on github's cloud side ? We're going to wonder what's the issue every time for nothing (in fact we already did for the upgrade of type-toml which is a minor package that should not make the execution time longer, and for pytest where it was legitimate to check. I don't think time is a reliable benchmark for performance when we don't control or even know what machine the code is run on.
|
@Pierre-Sassoulas I think (but I said that before) that #5827 should really solve these issues. Nevertheless, these timeouts did actually show a real issue with our tests (wrongly assuming the number of available cores). If there is something actually broken with GitHub cloud services we might want to remove them, but considering that I have not seen any news or comments within the larger python community about problems with If everything is good then these timeouts should never be reached and can thus be used to spot problems earlier (instead of after the default 6 hours). If the identified problem is with Github Cloud we can still merge as we just need them to update it. But if the identified problem is with us these timeouts will probably help debugging such issues as you're not unnecessarily waiting for something to time out after 30 minutes. |
Pull Request Test Coverage Report for Build 1882370291
💛 - Coveralls |
Type of Changes
Description
As discussed in #5816.
I'm confident that these times are more than enough. If we exceed them it is not due to tests really taking that long but rather because something else is broken. Actually helps to see that sooner rather than later.