8 added a global api configuration, which allows one Travis CI API endpoint to be configured.
As it is global, and only holds a single URL, it does not allow multiple travis servers to be used together.
The API end point (.org vs .com) should determined automatically based on whether the github repo is public or private. That should be relatively easy, as public vs private are mutually exclusive, and it can be determined at runtime using the github API. The list of github repos and their public/private status needs to be stored somewhere, to avoid needlessly hitting the github API for a list of all user repos (which can be a very long list, and cause a long delay for users with many orgs with many projects).
It could also be useful to support multiple Travis Enterprise CI servers. If there are multiple Travis Enterprise CI servers, we can not simply round-robin ask each if they know a server, as that would inadvertently leak private info. IMO the simplest immediate solution for multi Travis Enterprise CI servers is for these targets to be recorded using URLs. When given a Travis Enterprise Web URL, we can determine its API url by fetching the web url, getting the meta element name="travis/config/environment", and decoding the JSON content it contains, which contains e.g. "apiEndpoint":"https://api.travis-ci.org". Again the web URL->api URL needs to be stored in a cache to avoid fetching web URL pages frequently.
8 added a global
apiconfiguration, which allows one Travis CI API endpoint to be configured.As it is global, and only holds a single URL, it does not allow multiple travis servers to be used together.
The API end point (.org vs .com) should determined automatically based on whether the github repo is public or private. That should be relatively easy, as public vs private are mutually exclusive, and it can be determined at runtime using the github API. The list of github repos and their public/private status needs to be stored somewhere, to avoid needlessly hitting the github API for a list of all user repos (which can be a very long list, and cause a long delay for users with many orgs with many projects).
It could also be useful to support multiple Travis Enterprise CI servers. If there are multiple Travis Enterprise CI servers, we can not simply round-robin ask each if they know a server, as that would inadvertently leak private info. IMO the simplest immediate solution for multi Travis Enterprise CI servers is for these targets to be recorded using URLs. When given a Travis Enterprise Web URL, we can determine its API url by fetching the web url, getting the meta element name="travis/config/environment", and decoding the JSON content it contains, which contains e.g.
"apiEndpoint":"https://api.travis-ci.org". Again the web URL->api URL needs to be stored in a cache to avoid fetching web URL pages frequently.