Can we provide an option to specify an existing self-hosted runner?

[autocloudarc]

Description

Rather than only relying only on ALZ provided Azure Container Instances as self-hosted runners, I believe a large majority of cloud engineers and architects may want to leverage their existing GitHub Enterprise [Server, Cloud, or EMU] self-hosted runners that are configured internally as a shared runner at the enterprise or organization level instead.

Describe the solution you'd like

So, to accommodate these scenarios, can we offer an option as a parameter for the Deploy-Accelerator cmdlet to specify the [preferred] name or label of an existing Enterprise or Organizational level self-hosted runner or runner group that these engineers / architects would prefer to use. This way they can implement a simpler and less costly option while utilizing their existing investment in their own self-hosted runner(s).

Describe any alternatives you've considered

For private or internal repositories for GitHub Enterprise members, the alternative is to set the "use_self_hosted_agents:" parameter to "false", but in such cases, the self-hosted runners would then have to be specified in the GitHub Enterprise workflow post ALZ bootstrap, which requires an extra and manual step.

Additional context

[jaredfholgate]

This is a good idea. We are planning to replace the self-hosted runners code with the https://github.com/Azure/terraform-azurerm-avm-ptn-cicd-agents-and-runners AVM soon. This will allow choosing between ACI, ACA and Azure Managed DevOps Pools. We can also add an option that allows specifying an agent pool or runner group name at the same time.

e.g.

Variables:

• self_hosted_agent_type - Options: azure_container_instance, azure_container_app, azure_managed_devops_pool, custom
• self_hosted_agent_pool_name or self-hosted-agent-runner-group - String