From 41700cd958f691ee5c81d4cd139f95252d3822bf Mon Sep 17 00:00:00 2001 From: Gabriel Adrian Samfira Date: Sat, 10 May 2025 06:14:38 +0000 Subject: [PATCH] Slight rewording Signed-off-by: Gabriel Adrian Samfira --- doc/scalesets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/scalesets.md b/doc/scalesets.md index 2bbd1a8e..867f8f61 100644 --- a/doc/scalesets.md +++ b/doc/scalesets.md @@ -81,7 +81,7 @@ That's it. You now have a scale set created, ready to accept jobs. ## Scale Set vs Pool -Scale sets are a new way of managing runners. They were introduced by GitHub to enable more efficient scheduling of runners using their own Actions Runner Controller (ARC) project. Scale sets are meant to reduce API calls, improve reliability of message deliveries and improve efficiency of runner management. While webhooks work great most of the time, under heavy load, they may not fire or they may fire while the auto scaler is offline. If webhooks are fired while GARM is down, we will never know about those jobs unless we query the current workflow runs. +Scale sets are a new way of managing runners. They were introduced by GitHub to enable more efficient scheduling of runners. Scale sets are meant to reduce API calls, improve reliability of message deliveries to the auto scaler and improve efficiency of runner scheduling. While webhooks work great most of the time, under heavy load, they may not fire or they may fire while the auto scaler is offline, leading to lost messages. If webhooks are fired while GARM is down, we will never know about those jobs unless we query the current workflow runs. Listing workflow runs is not feisable for orgs or enterprises, as that would mean listing all repos withing an org then for each repository, listing all workflow runs. This gets worse for enterprises. Scale sets on the other hand allows GARM to subscribe to a message queue and get messages just for that scale set over HTTP long poll.