You will need to set memory requirement of your memory consuming jobs to reflect peek memory usage, so that OneDev can queue some of them when resource is in short.

Thank you @robin . This is the memoryRequirement in the .onedev-buildspec.yaml, right? One of my concern is that a developer may not know ahead of time how much resources the build will end up using and/or might forget to set it on a particular project or branch, easily bringing the whole system down (scenario requiring the reset button and leading to #1055). Perhaps setting the docker resources constraints is one way to address it?

I was wondering if perhaps it would make sense to set a global minimum memoryRequirement that onedev could assume e.g., setting it to 2000 with a 4000 total memory would force it to have a maximum of 2 builds running at the same time, regardless of what developers put in the .onedev-buildspec.yaml? The idea is that the admin is responsible for the stability of the system and therefore is more trustable than the developers to define resource requirements.

This could be used together with the docker constraints. Without this however, if I set my docker constraints to 2 GB, onedev will probably still run more than 2 docker executors concurrently and I will still run into the same issues (if the memoryRequirement in the .onedev-buildspec.yaml are not accurate).

Jobs consume considerable resources should specify meaningful cpu/memory requirement. For jobs you do not trust or do not have control over, use a particular job executor running on designated agents in order not to affect your important jobs.

Thinking more about this. Specifying cpu/memory limit and concurrent jobs at executor level seems like a more natural approach. Turning this into an improvement request.

Awesome, thank you :) Wishing you and yours all the best, and all the success to OneDev that it deserves for 2023.

State changed as code fixing the issue is committed

State changed as build #3255 is successful