In hydra, it often happens that an evaluation completion is waiting on a handful of tests and/or builds to finish which are completely stuck. For example, in the current eval, the ejabberd test is "running" on both x86_64 and aarch64 and will continue doing so for the next ~5h.
Not only does delay the eval completion unnecessarily, it also delays other jobs of the current eval because the limited amount of builders are busy with useless work. For example, an nginx test and a few Bitwarden tests are waiting on the broken ejabberd test righ now.
Broken tests should obviously be fixed or marked as broken but I think they shouldn't be able to do as much "damage" when they happen to break and stay broken for a while.
The vast majority of packages and tests should complete in well under 10h. Even something as big as Chromium only takes ~2h to compile. I think it might be a good idea to set a much, much lower default timeout and exempt select "large" jobs.
Issue description
In hydra, it often happens that an evaluation completion is waiting on a handful of tests and/or builds to finish which are completely stuck. For example, in the current eval, the ejabberd test is "running" on both x86_64 and aarch64 and will continue doing so for the next ~5h. Not only does delay the eval completion unnecessarily, it also delays other jobs of the current eval because the limited amount of builders are busy with useless work. For example, an nginx test and a few Bitwarden tests are waiting on the broken ejabberd test righ now. Broken tests should obviously be fixed or marked as broken but I think they shouldn't be able to do as much "damage" when they happen to break and stay broken for a while.
The vast majority of packages and tests should complete in well under 10h. Even something as big as Chromium only takes ~2h to compile. I think it might be a good idea to set a much, much lower default timeout and exempt select "large" jobs.
cc @NixOS/infra @NixOS/hydra-triage