Runner load balance

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem (s)

  1. When pipelines start with a number of jobs that equal or are less than the concurrent setting for runners all jobs are sent to a single runner because runners are set to pull as many jobs as they can today. This can result in a slower than expected pipeline time for this kind of pipeline.

  2. How do we prioritize builds in the queue?

Example/Use case

For example, we have two servers with runners, which can handle up to 30 concurrent jobs. But our pipeline consists of 12 jobs. So when we push to gitlab some changes - it fills only one server (all 12), and only after server is full - send jobs to another. It is a very strange behavior, because from limited CPU jobs uses more time, than needed.

Proposal

Use round-robin or same, to balance each job in pipeline between servers.

Current workarounds

  • Set a smaller value for concurrent but this results in over-provisioned runners
  • Use tags to send jobs to specific runners but this requires extensive knowledge about the jobs needs and runner capabilities
Edited by 🤖 GitLab Bot 🤖