Deploying controller to support multiple github organizations

[tzejohn]

Is there any guidance around deploying this controller in a single EKS cluster to support multiple different GitHub organizations? We have a couple GitHub.com hosted organizations, as well as an on-prem Github Enterprise instance. I was looking to support all of those with actions runners running in the same EKS cluster.

[callum-tait-pbx]

You probably want to explore deploying multiple controllers using the watchNamespace feature, it's not really documented unfortunately. The feature was added as part of actions/actions-runner-controller#377, you might be able to gleam more details from the issue.

@mumoshu can provide more details if you get stuck

[mumoshu]

Yeah, if you also need to isolate each organization('s runners) into a dedicated namespace, --watch-namespace should be handy.

In the Helm chart it is configurable via:

https://github.com/summerwind/actions-runner-controller/blob/b42b8406a2b6d606ef9b531867720039e1de1b42/charts/actions-runner-controller/values.yaml#L103-L104

Also, if you're okay with sharing the GitHub token/app and the namespace across GitHub orgs, I believe just creating RunnerDeployments with various organization field values work.

[ionutzaharia]

How would this work when using the same GitHub Application with multiple organizations that installed the application?
The issue is with the github_app_installation_id that points to a single organization github app installation.
The runnerdeployments that point to other organizations return a 403 even though the app is installed and the permissions are correct? Is the github_app_installation_id variable obligatory? Can we provide multiple installation IDs?

[callum-tait-pbx]

How would this work when using the same GitHub Application with multiple organizations that installed the application?

It wouldn't. The namespace feature lets you deploy a controller to namespace and have it only watch runners deployed in that namespace thus enabling you to deploy multiple controllers (all using their own GitHub App all deployed in their own namespace) on a single cluster.

The alternative is you setup a single controller and deploy runners at the enterprise level https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#about-self-hosted-runners however you are limited to using PAT authentication if you go down that route.

[rxa313]

It wouldn't. The namespace feature lets you deploy a controller to namespace and have it only watch runners deployed in that namespace thus enabling you to deploy multiple controllers (all using their own GitHub App all deployed in their own namespace) on a single cluster.

Is there an example of this anywhere? I was able to deploy two runners against two separate organizations in their own namespaces but I'm not sure if the controller itself is doing anything with them.

I have a namespace "actions-runner-system" that has the controller deployed, a namespace called "gitactions-one" that has one org runner in it, and a third namespace called "gitactions-two" that has another org runner in it. They are running and working. How do I know if the controller is actually doing anything with these?

NOTE: I also had to deploy these org runners by running the helm uninstall, then doing helm upgrade install and applying the values.yaml that had the other orgs GitHub app ID configuration in it.

The operation looked like this:

1. Helm upgrade --install .... -f values.yaml (this values.yaml has one orgs GitHub App info in it)
2. kubectl apply -f runnerdeployment.yaml -n gitactions-one
3. helm uninstall actions-runner-controller -n actions-runner-system
4. helm upgrade --install ... -f values-xxx.yaml (this values.yaml has the other orgs GitHub App info in it)
5. kubectl apply -f runnerdeployment-xxx.yaml -n gitactions-two

Any insight would be appreciated.

[mumoshu]

Please let me move this to Discussions as the question is already answered, the feature that supports the use case already exists, and the documentation enhancement is tracked in another issue #455.