backstage: Catalog import open PR doesn't support GitHub Enterprise yet

Expected Behavior

When submitting the URL of a GitHub Enterprise repo to the register component screen, the pull request is opened on the GHE instance.

Current Behavior

GitHub.com is hardcoded and so won’t open PRs on GHE. User always receives HTTP 401 unauthorized.

Octokit library defaults to GitHub.com when not otherwise specified:

https://github.com/backstage/backstage/blob/257619c1ee9c49454fc32b6d7d2b07283ea8d738/plugins/catalog-import/src/api/CatalogImportClient.ts#L101-L103

Also hardcoded here:

https://github.com/backstage/backstage/blob/257619c1ee9c49454fc32b6d7d2b07283ea8d738/plugins/catalog-import/src/api/CatalogImportClient.ts#L180-L183

Possible Solution

The OAuth provider objects don’t seem to maintain the enterprise URL separately today, so I think if we query the config and get enterpriseInstanceUrl it could be used when instantiating the Octokit object.

Roughly this code:

https://github.com/backstage/backstage/blob/257619c1ee9c49454fc32b6d7d2b07283ea8d738/plugins/catalog-import/src/api/CatalogImportClient.ts#L90-L103

Would maybe need something along these lines though I wasn’t able to get the plumbing from this component to the config working properly:

    const token = await this.githubAuthApi.getAccessToken(['repo']); 
    const configApi = useApi(configApiRef);
    const enterpriseInstanceUrl = configApi.getOptionalString('auth.providers.github.enterpriseInstanceUrl'); 
    const octo = new Octokit({
      auth: token,
      baseUrl: enterpriseInstanceUrl,
    });

The Octokit object just takes the baseUrl as a param.

Steps to Reproduce

Register a component manually (e.g., http://localhost:3000/catalog-import )
Enter a GHE instance URL (even a fake one) in the form https://ghe.mycompany.com/org/repo, click Next
The review step CORRECTLY shows the target URL, though note the annotation is incorrect - it uses only the last part of the host and .com, in this example will only show “mycompany.com” when it should likely be hardcoded to github.com per the slug
Click Next, receive HTTP 401 from GitHub.com

Context

Your Environment

NodeJS Version (v12): v12.16.2
Operating System and Version (e.g. Ubuntu 14.04): Windows 10 1909 WSL2 Ubuntu 18.04
Browser Information: Microsoft Edge (Chrome engine 87)

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (15 by maintainers)

Most upvoted comments

If you can easily hold off without ill effects then maybe that’s safer. I gotta say that it’s tempting to define this just as either the shorthand slug (assuming you have one provider, or it picks the “top” one), or the full URL to the repo (e.g. https://github.com/dxc-technology/online-devops-dojo) if one needs to discern between several. But again … not defined quite yet and consumers will then need a facility to reliably parse what they need out of it. Which will be available when the packages/integration package is fleshed out later.

freben on Dec 14, 2020

Sorry, the situation is the same. Until it’s resolved, we recommend registering full YAML urls instead of directories. That flow should work perfectly for your GHE.

freben on Mar 16, 2021

Yep, that code took a shortcut to easily support a couple of the most common public providers. It will need to be updated to instead read from the integrations config (with the help of the packages/integration package) to find what provider that the URL actually pointed to.

However, even if this annotation got the right key, as in for example github.com/project-slug, one potential problem remains - we haven’t yet set in stone a format for the value, which lets you discern between various providers. If you for example have integrations both toward public github and an internal github enterprise, there isn’t a well known format for encoding which one you mean in this annotation. Most do NOT have more than one though, so we could always just pick the first match and go with that in the mean time.

freben on Dec 14, 2020