v0.6.0 scale-set breaks the ability to have 2 runner install with the same name

[ba-work]

Checks

• I've already read https://github.com/actions/actions-runner-controller/blob/master/TROUBLESHOOTING.md and I'm sure my issue is not covered in the troubleshooting guide.
• I'm not using a custom entrypoint in my runner image

Controller Version

v0.6.0

Helm Chart Version

v0.6.0

CertManager Version

No response

Deployment Method

Helm

cert-manager installation

no cert manager

Checks

• This isn't a question or user support case (For Q&A and community support, go to Discussions. It might also be a good idea to contract with any of contributors and maintainers if your business is so critical and therefore you need priority support
• I've read releasenotes before submitting this issue and I'm sure it's not due to any recently-introduced backward-incompatible changes
• My actions-runner-controller version (v0.x.y) does support the feature
• I've already upgraded ARC (including the CRDs, see charts/actions-runner-controller/docs/UPGRADING.md for details) to the latest and it didn't fix the issue
• I've migrated to the workflow job webhook event (if you using webhook driven scaling)

Resource Definitions

I use to install the runners with flux like this:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: repo-1
  namespace: arc-runners
spec:
  values:
    runnerScaleSetName: ci-cluster # <-- note that this has the same value in repo-2
    ...
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: repo-2
  namespace: arc-runners
spec:
  values:
    runnerScaleSetName: ci-cluster # <-- note that this has the same value in repo-1
    ...

To Reproduce

helm install repo-1 \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set \
    --set runnerScaleSetName=ci-cluster
helm install repo-2 \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set \
    --set runnerScaleSetName=ci-cluster

Describe the bug

I use to install the runners with flux like the included HelmReleases suggest; they could have the same value for runnerScaleSetName and workflows in different repos could both target ci-cluster. With v0.6.0 (this commit: 837a1cb) the resources overlap and it doesn't work with no ability to override/workaround.

Describe the expected behavior

The runner groups/scalesets are created with the same name in each repo, like they were in v0.5.0

Whole Controller Logs

this isn't relevant, the bug is related to helm templating

Whole Runner Pod Logs

this isn't relevant, the bug is related to helm templating

Additional Context

had to revert to 0.5.0 since this change breaking all workflows in repo-2 that expect to be able to target ci-cluster

[github-actions[bot]]

Hello! Thank you for filing an issue.

The maintainers will triage your issue shortly.

In the meantime, please take a look at the troubleshooting guide for bug reports.

If this is a feature request, please review our contribution guidelines.

[ba-work]

some more info, this works on 0.5.0 because both AutoscalingRunnerSets have different names, but have the same annotation: runner-scale-set-name=ci-cluster

[Link-]

@ba-work - this worked previously because of a bug in our charts which was fixed in 0.6.0. The isolation model we designed for is:

1. Runner scale set name is unique per runner group (you can have multiple runner scale sets with the same name, if they belong to different runner groups)
2. Runner scale set name is unique per namespace

You were never supposed to be able to create 2 runner scale sets with the same name in the same namespace. Even if they were registered against different repositories, organisations or enterprises.

You can read more about this here: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller#using-arc-across-organizations

[ba-work]

Thanks for the answer, I can convert my deployments to have distinct namespaces. Even though I'm not "supposed to", it still works if I manually deploy the resources with the appropriate annotations. Another problem with v0.6.0 (aside from my misuse) was that a second helm release clobbered a bunch of resources from the first helm release with only a matching runnerScaleSetName.

The chart could prevent overwrites like that by using helm's lookup function and then throw an error (or warn) if an install will violate the isolation model or cause overwrites.

[samus-aran]

We're locking this discussion because it has not had recent activity and/or other members have asked for more information to assist you but received no response. Thank you for helping us maintain a productive and tidy community for all our members.