Our GitHub enterprise team is complaining that we are calling the /rate_limit API excessively which is causing issues since we don't even use rate limiting on our instance.

I have tracked down the last usages of the API to the readTrusted step which uses the GitHub API to retrieve the file from GH. In this case, it does not configure the thread checker and we get this error:

LocalChecker for rate limit was not set for this thread. Configured using system settings.

Since it always assumes the public GitHub API endpoint for this case, it also does not allow disabled throttling, so we see this message just after:

GitHub throttling is disabled, which is not allowed for public GitHub usage, so ThrottleOnOver will be used instead. To configure a different rate limiting strategy, go to "GitHub API usage" under "Configure System" in the Jenkins settings.

However, in this case the plugin does not directly use the GitHub branch source plugin (and probably should not). I believe the root of the problem is the decision to use the public GitHub URL combined with the disabling of throttling when using the public GitHub URL. Instead, we should attempt to use the first configured GitHub URL from the system configuration. If none is configured, we can fallback to the public GitHub URL as before. This should satisfy both use cases and maintain previous behavior no matter which plugin might use the SCM source without knowing it's a GitHub branch source.

UPDATE: I found an additional instance when rate limiting is used, even if explicitly disabled. This occurs when performing connection validation. I added another clause to the connection check: if rate limiting is disabled, it uses the meta endpoint instead of rate limits. I have validated this behavior both ways on my Jenkins server. This was causing 1200+ calls to the rate limit API per day for us.