wiki: claim order stays oldest-first !359

merged merged by cmc on 2026-09-10 01:56 UTC · krz/gitbay:claim-order-decided into main

2 files changed, +7 −4

Layout: unified · split

.gitbay/wiki/Admin.org +4 −2

	@@ -399,8 +399,10 @@ Oldest-first is across everything the key may claim, so a repository
399	with a deep queue holds every other repository the same runner serves;	399	with a deep queue holds every other repository the same runner serves;
400	bay1 measured a 15-minute average wait on a day of merge request	400	bay1 measured a 15-minute average wait on a day of merge request
401	stacks from one repository. A runner attached to one repository cannot	401	stacks from one repository. A runner attached to one repository cannot
402	be starved. Whether a runner serving several rotates across them is	402	be starved. That is the rule, decided in krz/gitbay#207: a runner
403	krz/gitbay#207. Nothing caps what an account queues: builds pending at	403	serving several repositories takes them oldest-first, and an operator
		404	who wants one repository never to wait on another runs a second
		405	runner attached to it alone. Nothing caps what an account queues: builds pending at
404	once and schedule intervals down to a minute are unbounded, and a	406	once and schedule intervals down to a minute are unbounded, and a
405	build nothing claims stays pending. Since a build runs only on a	407	build nothing claims stays pending. Since a build runs only on a
406	runner its owner attaches, the cost is rows and the queue numbers on	408	runner its owner attaches, the cost is rows and the queue numbers on

.gitbay/wiki/CI.org +3 −2

 admin key), and an untrusted build only by one started with
 =-untrusted=. A repository with no runner attached queues builds
 nothing claims. See the Users page. Among what a runner may claim it
-takes the oldest pending build; per-repository rotation when one
+takes the oldest pending build, across every repository it serves;
-runner serves several is krz/gitbay#207. There is no cap on how many
+a repository that must never wait on another gets a runner of its own
+(decided in krz/gitbay#207). There is no cap on how many
 builds an account queues or how often a schedule fires; that is
 krz/gitbay#206.