Replies: 4 comments 3 replies
-
| +1, exact same setup for me right now with the exact same use case. We're using EKS and cluster-autoscaler to also dynamically scale the ASG providing nodes for our CI Runners. Then RunnerSets and HorizontalRunnerAutoscaler on top. Our node group for CI Runners has labels and taints so that ARC runner pods are the only pods scheduled to each node. We have very large container images (5GB+) that our GH workflows are using, so we need to keep images around using PVs so that we're pulling a 5GB image every time a new runner pod is created. | 
Beta Was this translation helpful? Give feedback.
-
| Yes, what we need in the newer version is the ability to choose between a StatefulSet or Deployment style of pod provisioning. If we could use StatefulSets, disks should be re-used while pods could still be scaled in and out... | 
Beta Was this translation helpful? Give feedback.
-
| Any updates here? We also need non-ephemeral CI runners, as our build system (nix and bazel) will take care of the reproducibility, and nix is de-facto uncacheable (at least not efficiently, given our project size). It looks like the "stateful" approach is not a supported mode in the new ARC world | 
Beta Was this translation helpful? Give feedback.
-
| 🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as  2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the  Thank you for helping bring this Discussion to a resolution! 💬 | 
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm currently using the legacy
RunnerSet(actions.summerwind.dev/v1alpha1) resource. This allows me to have volumes that are mounted into the pods that persist between workflow runs. This feature is very useful and (for me) this is the primary reason why I need self hosted runners in the first place.Can the new
Autoscaling Runner Scale Setsstill be used in this way or will I need to stay on the old version? The docs do not include clear guidance on this.I would love to see and end-to-end example that has the same semantics as described here: actions/actions-runner-controller#2484
Beta Was this translation helpful? Give feedback.
All reactions