-
Hi everyone! We're currently looking at deploying controllers in multiple namespaces inside of an EKS cluster using Helm charts. I wanted to do one separate controller for each GitHub organization that was a part of our enterprise. I believe that I have the controllers configured correctly (each watching their own namespace, runners going into correct namespaces). So, this solution works for one namespace, let's call it "ns1". The chart installed fine, and the controller is handling workflows better than I ever considered it would. Unfortunately, if I try to do a separate chart deployment to another namespace, let's call it "ns2", I get the following error:
I assume by this error that some of the installed resources are global and non-namespaced. I'm still working my way through understanding exactly how Kubernetes works, so I wanted to ask if anyone has any ideas about what we might be doing wrong with our helm charts? Is there something I'm not considering or overlooking in the documentation? Also, is there a simple way of resolving this issue? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I think you'll need to specify different names for the release and the webhook by specifying fullnameOverride and githubWebhookServer.fullnameOverride. helm upgrade --install \
--namespace $(Namespace) \
--create-namespace \
--set scope.singleNamespace=true \
--set authSecret.create=true \
--set authSecret.github_token=$GITHUB_TOKEN \
--set fullnameOverride=$(Name) \
--set githubWebhookServer.fullnameOverride=$(WebhookName) \
--wait $(Name) actions-runner-controller/actions-runner-controller |
Beta Was this translation helpful? Give feedback.
I think you'll need to specify different names for the release and the webhook by specifying fullnameOverride and githubWebhookServer.fullnameOverride.
example: