Mobile CI/CD Runner Pool: Build Queue & Cache Simulator (2D)

Pipeline Parameters

Parallel runners 3

Commit arrival rate 30/hr

Build-cache hit rate 55%

Test flakiness (fail rate) 12%

Live Readouts

Avg queue wait

0.0 min

Throughput

0.0 /hr

Runner utilization

Waiting in queue

Deployed / failed

0 / 0

Queued Checkout Build Test Sign & deploy Failed

How it works

Each pushed commit is a job that must pass through four pipeline stages in order — checkout → build → test → sign & deploy — before it reaches release. A fixed pool of c parallel runners pulls jobs off a FIFO queue; a job waits whenever every runner is busy, and one runner carries a job through all four stages before picking up the next.

Build stage time  Tb = Tb0 · (1 − 0.65 · cacheHitRate)
Test outcome      fail with probability p = flakyRate
                  (failed job re-queues, up to 3 attempts)
Little's Law      L = λ · W
  L = jobs resident in the pipeline (queue + in-flight)
  λ = effective commit arrival rate
  W = mean total time a job spends in the system

Build-cache hits shorten only the build stage, since checkout, test and signing are unaffected by compiled-artifact reuse. Runner utilization is the fraction of total runner-minutes spent processing a job rather than sitting idle — push arrival rate past what c runners can drain and utilization saturates near 100% while the queue (and wait time) grows without bound, the same saturation behavior real CI fleets hit when too few self-hosted runners serve too many pull requests.

Runners — how many jobs can be in-flight (checkout/build/test/sign) at once.
Arrival rate — how often a new commit lands in the queue.
Cache hit rate — fraction of builds that reuse compiled artifacts instead of a cold rebuild.
Test flakiness — probability a passing build still fails at the test stage and must retry.