Skip to content

Simplify usage of GitHub repos w/o repo-scope access token

Created by: sqs

As a site admin setting up a Sourcegraph instance, I want to try it out with less risk and effort.

  • Less risk: I might not feel comfortable putting in an access token with repo scope (which includes read/write access to private repositories). Even though Sourcegraph is self-hosted and never sends my code anywhere, I might not trust that yet. Or if I trust it, I might think it might have other features that would do things like automatically update my repository (it doesn't, but I might not know that). Finally, I might be OK with all of these things, but if I'm screen-sharing with Sourcegraph folks, I might not want them to watch my screen as I create an access token.
  • Less effort: I might want to just try it on some repositories without going through the task of creating an access token on GitHub or GitHub Enterprise.

Proposed solutions:

  1. Document that users can create a GH access token with public_repository scope (instead of repo scope) if they want. (Technically this access token, if visible during screen-sharing, could still lead to unauthorized access, but the perceived risk by site admins is accurately much lower.)
  2. LESS IMPORTANT: Allow saving a GitHub external service config without a personal access token. In this case, warn the site admin that they will be severely rate-limited by the GH API (60 requests per hour, vs. 5000 requests per hour with a token), perhaps in a non-dismissible global alert at the top of the page. We would need to confirm the experience is OK and doesn't immediately exhaust the rate limit. The recommended path would still be to add an access token, and we wouldn't want to add confusion that would lead to some site admins mistakenly not providing an access token.

Context: This would have caused one specific customer demo that @KattMingMing and I did to have gotten further. The person ran a Sourcegraph instance locally (while screen-sharing with us) but decided not to add an access token and instead asked us to demo.