Replies: 1 comment
-
Not sure if this might be helpful in your case, but our team manages an enterprise instance with 20+ orgs and we decided to stand up only a few scale sets (some for linux and some for windows) that deploy enterprise runners across all orgs. We were able to keep the number of scale sets to a minimum by creating several docker images tailored to each type of job and injecting them into the runner container hook extensions via GHA workflows so that the worker pod that gets spun up by the k8s runner pod is very flexible in it's functionality. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Dear ARC Community,
We're looking to implement better attribution of runs, as in particular Docker-in-Docker GitHub runners have nothing to distinguish runs on them as compared to Kubernetes runners which at least say what image they're running.
We have something like 15 organizational teams, with initially 3 types of runners in a single GitHub org, so if we blindly made Scale Sets distributed across namespaces we would have 45 permutations of Actions runners.
One idea we had was use a mutating web hook of some kind to assign labels to a job run after starting, but we worried how reliable that would be.
Anyone have experience with this approach?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions