Autoscaling capability for number of concurrent machines

#1

Description of the feature request

Add capability to make the number of concurrent builds to be “elastic” – i.e. if the workers are all exhausted and there are lots of queued jobs, maybe automatically increase the number of workers temporarily by (lets’s say) 20% during the next 3 days?

Use case / for what or how I would use it

Depending on our schedule, the number of concurrent machines that we need may fluctuate. For example, during our testing period workers utilization should be much higher than normal.

(Additionally, would be great if we can also see the workers statistics – utilization rate, busiest times, etc.)

0 Likes

#2

Hi @dvdchr-tvlk,

Thank you for the #feature-request!
This would definitely be a useful feature to have. Currently the number of concurrencies can be changed on a monthly basis, so if we’d introduce something like this we’d need to hash out the pricing implications and edge cases. Pay-as-you go is not something we are currently considering, although this seems like an option in between monthly subscription and pay-as-you-go.

I suppose this loosely ties into this feature request: Limit concurrency on specified (deploy) branches, or on project/app level (only allow X concurrency for app Y) With better allocation of your resources you could more easily avoid getting on hold builds where you need throughput the most.

Better reporting for build performance and build stats is definitely planned so you could better track build times, time spent in queue, etc.

2 Likes