Self-hosted Servers cannot support both v3 and v4 based badges with GitHub Enterprise Server

[calebcartwright]

Discussed in https://github.com/badges/shields/discussions/6909

TL;DR, GitHub uses different API routes for their cloud/SaaS products and their Server/self-hosted Product:

Cloud/SaaS: v3: https://api.github.com/{api-path}/{params} v4: https://api.github.com/graphql/{api-path}/{params}

Enterprise Server: v3: https://server/api/v3/{api-path}/{params} v4: https://server/api/graphql/{api-path}/{params}

The way we wired up the paths for the various GitHub pages is coded to the Cloud/SaaS model, which in turn forces self-hosted Shields users to essentially have to pick either the v3 or the v4 badges in a mutually exclusive way (i.e. set GITHUB_URL=https://server/api/v3 if you want the v3 based badges and no v4 badges, or GITHUB_URL=https://server/api/ for the opposite)

^{Originally posted by ericscheidemantle-dreamworks August 18, 2021} I've found and successfully set my GITHUB_URL but have yet to figure out how to handle the fact that the REST API uses /api/v3 but the GRAPHQL doesn't. If I set GITHUB_URL to https://myserver/api/v3, some end points like /github/last-commit/:user/:repo work fine, but ones using /graphql, like /github/issues-pr/:user/:repo fail because an invalid URL is constructed.

Is there a configuration option to solve this?

[calebcartwright]

Not sure the best way to handle this. IIRC we essentially assume that if GITHUB_URL is set then we're working with GitHub Enterprise Server (GHES), so I imagine one option would be to take advantage of the presence of the var and use an updated base url on the v3 calls. I.e. for a v3-based badge we use ${baseUrl}/v3 (evals to https://my-enterprise-server/api/v3) while the v4/graphql calls still go to https://my-enterprise-server/api/graphql).

Perhaps another, albeit one with some duplication, would be to add a new var that allows the user to configure the url for the v4 endpoints, e.g. GITHUB_URL=https://my-enterprise-server/api/v3, GITHUB_V4_URL=https://my-enterprise-server/api (as odd as that looks)

[chris48s]

assume that if GITHUB_URL is set then we're working with GitHub Enterprise Server (GHES), so I imagine one option would be to take advantage of the presence of the var and use an updated base url on the v3 calls.

I think this is a valid assumption. That's what we've said GITHUB_URL is for in the docs: https://github.com/badges/shields/blob/master/doc/server-secrets.md#github

[calebcartwright]

Part of my hesitation there is the uncertainty around other GitHub offerings like AE. Enterprise Cloud (EC) is on the same URI patterns as standard GitHub.com (i.e. api.github.com), but unlike the multitenant EC, AE is a dedicated tenant that could have both a different base url that would need to be set, but with the same API path patterns as cloud.

I don't want to block on the AE scenario since AFAIK it's still in a private preview with scant details, but probably at least warrants some inline comments

[chris48s]

Another possible option if we've got multiple different scenarios we need to deal with would be to keep GITHUB_URL around working as it currently does but mark it as deprecated. Then introduce some new settings for example: GITHUB_GHES_BASE GITHUB_EC_BASE GITHUB_AE_BASE which can work slightly differently if needed. Then if someone is using GITHUB_URL for one of those things and it works, they can keep doing what they are doing - we won't break or remove GITHUB_URL, but if they hit an issue with it (e.g: the one described) then they can switch to using one of the new settings as appropriate and we can use them to make unambiguous assumptions and we are covered if and when those products diverge. I guess this would introduce some additional (maybe unnecessary) complexity for us though.

[Elaniobro]

Any update/movement on this? I too would ❤️ the use of both v3/4 badges on a self hosted GHES instance.