Fix bug with enterpriseURL for multi-tenancy

[bm1216]

Addresses and fixes #1764.

Changes:

• Add IsEnterprise bool to the GitHub client struct. It is set when the client is an enterprise client.
• Check if the main client is an enterprise client before setting conf.EnterpriseURL for clients created using githubAPICredentialsFrom.
• Add command line argument for setting EnterpriseURL in GitHub config.

Reasoning

Currently, ARC creates a GitHub client (let's call it client A) when the controller is created - this client is passed to the RunnerReconciler. As part of the multi-tenancy feature, a new client (let's call it client B) is created when a RunnerDeployment is added with the field githubAPICredentialsFrom.

The GitHub wrapper creates a client from a config struct. When creating client B, it sets the enterpriseURL in its config to the GithubBaseURL of client A¹. This causes issues when client A is not an enterprise client, as client B now has its enterpriseURL defined. The GitHub wrapper behaves differently when an enterpriseURL defined in the config struct, leading to the newly created client B calling the wrong API endpoint for tasks such as runner registration.

To fix this, client A needs a basic idea of whether it is using an enterpriseURL. We have decided to use a bool (as opposed to doing checks on the baseURL) as it's just cleaner and less likely to go wrong.

Also, added command line support for enterpriseURL as it was the only thing that was missing.

¹ This was introduced as part of #1725 and issue #1714. The concern was valid because if the config for client B has no enterpriseURL defined it should be using the enterpriseURL of the original client (A). Nevertheless, the above bug was introduced.

[bm1216]

@Jalmeida1994 for visibility. I tested it out and it should still work for your use case.

[bm1216]

@mumoshu @toast-gear thoughts?

[mumoshu]

Thank you very much for diagnosing and fixing it! I love your detailed explanation of the issue and the fix too-it helped me quickly understand and confirm this is the right fix!

Definitely LGTM 👍

[Jalmeida1994]

@Jalmeida1994 for visibility. I tested it out and it should still work for your use case.

Hey @bm1216 nice work! When I get the time I'll test it also on an Enterprise Environment but the code and the reasoning makes sense! Cheers, and sorry again for introducing this bug @mumoshu @toast-gear and @bm1216!

[bm1216]

Thanks @mumoshu @Jalmeida1994 for taking a look. Appreciate all the comments