multiple repos per pool? #294
-
|
is it possible to have multiple repositories per runner pool (without using organizations/enterprises)? that is, I would like to be able to define the pool once, but have it usable by multiple repositories. that way, the pool would be shared among the repos. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
Hi @rgl ! When dealing at the repository level, each repository may have different owners. Each owner will have their own PAT/App. And each repository will generate its own events. A runner gets registered within a repository, using credentials that belong to the owner (PAT) or an app that the owner has authorized to add runners on their behalf. A single pool cannot handle runners belonging to 2 different owners. And there is no technically feasible way to add it in GARM. Sharing a pool would also mean that within the same pool you'd have some runners registered in one repo and runners reistered in another. There is no way for asingle runner to be part of 2 repositories. The only way to share a pool is to create it at the org or enterprise level, as you suggested. |
Beta Was this translation helpful? Give feedback.
-
|
thank you for the clarifications! just to make it clearer, is this a garm or a github actions (self-hosted runners) limitation? PS: for my single-user use-case (I do not have an org or an enterprise), having to register a pool for each repo sounds like too much trouble to maintain. |
Beta Was this translation helpful? Give feedback.
-
|
A bit of both. Theoretically, it could be possible to do something like that in a project like GARM, but managing the pool would be a complete mess. When debugging, you'd have to determine which runner belongs to which repo. It's a nightmare both in terms of UX and code. We'd also have to add all sorts of checks to see if the 2 repos belong to the same user, or require the user to somehow specify 2 sets of credentials for the same pool. It breaks every architectural boundary in code and it will not be useful for users outside of being able to have just one pool that functionally will behave like 2 pools. |
Beta Was this translation helpful? Give feedback.
-
|
ah, thank you for another peek at the chocolate factory internals! will try to see how that is handled by an org runner. |
Beta Was this translation helpful? Give feedback.
-
|
an org pool is ideal when you have multiple repos with similar needs. Pools are a way to define a set of homogeneous runners. You can have multiple pools each with a different type of runners (with GPUs, with lots of RAM and less disk space, with tons of disk space and little RAM/CPU, etc). You can have as many pools as you want on a single entity (repo/org/enterprise) and you can target them with labels. I recommend you use a single unique label, instead of multiple labels. For examplem instead of using "linux,x64,large", you can create pools with a single label "linux-x64-large". It makes it easier to avoid mistales like using just one of the labels in the array, and inadvertently targeting a runner with lots of disk and littel CPU when you in fact needs lots of CPU and RAM, with little disk. |
Beta Was this translation helpful? Give feedback.
A bit of both. Theoretically, it could be possible to do something like that in a project like GARM, but managing the pool would be a complete mess. When debugging, you'd have to determine which runner belongs to which repo. It's a nightmare both in terms of UX and code. We'd also have to add all sorts of checks to see if the 2 repos belong to the same user, or require the user to somehow specify 2 sets of credentials for the same pool.
It breaks every architectural boundary in code and it will not be useful for users outside of being able to have just one pool that functionally will behave like 2 pools.