Repo name mappings are not universally supported
Created by: sqs
-
As a site admin, I want to be able to make my repositories on Sourcegraph have "nice names". (Not all site admins want this, but some do.) By that I mean I want them to be no longer than needed, like
foo/bar
insteadgithub.com/foo/bar
, orbaz/qux
instead ofmy-corporate-github-enterprise.internal.northamerica.my-long-company-name.net/baz/qux
.It is important to make them short because
- it makes Sourcegraph URLs shorter, which makes them easier to read and share
- it makes many
repo:
filters easier to type - places in the Sourcegraph UI that show the full repo name don't overflow due to taking up too much screen width.
-
As a user, I want to be able to jump from the repository on my code host or in my editor to the repository on Sourcegraph, even if the repository is not the full long name on Sourcegraph.
- From an impl POV, this means that it should be possible to map from the name of a repository on some other tool (e.g., a Git clone URL of
https://my-corporate-github-enterprise.internal.northamerica.my-long-company-name.net/baz/qux.git
on my local machine, or the Sourcegraph browser extension running on https://my-corporate-github-enterprise.internal.northamerica.my-long-company-name.net/baz/qux) to https://sourcegraph.example.com/baz/qux.
- From an impl POV, this means that it should be possible to map from the name of a repository on some other tool (e.g., a Git clone URL of
Current state:
-
repositoryPathPattern
has too much power and flexibility. It was a mistake to add such an option (it is my (@sqs) fault). The only cases we need to support are (1) the "fully-qualified" repo names (with hostname, egmy-corporate-github-enterprise.internal.northamerica.my-long-company-name.net/baz/qux
) or the path components only (egbaz/qux
).- I (@sqs) am not aware of any customers using more complex configs than that. If we discover any are, we can publish docs for adding nginx rewrite rules instead of needing to handle backcompat for these more complex cases.
Properties of solution:
- It is acceptable but not necessary for both the fully-qualified name and the path-only name to work.
- It is acceptable for all repositories from a given external service to have the same kind of naming (i.e., fully-qualified or path-only). It is not necessary to be able to set this on a per-repository basis.
- If the site admin changes how repositories are named, it must not leave a bunch of stray repositories around with the old naming scheme.
- Every instance in code where we check for a
github.com/
string prefix to a repo name should probably be fixed. - In all external service types other than
OTHER
, the source of truth of the name should be the code host. We should not allow users to come up with a custom alias for a repository that is hard-coded, because this will go stale if the repository is renamed.
Useful initial decisions:
- What is the API that the browser extension uses to map from a repository on a code host to the repository on Sourcegraph? What are the inputs?
- Same, but for editor extensions.
- Should the work for this issue only consist of the backend work, or also the work to actually update the browser extension and editor extensions to work with this new way of naming?
Related:
- https://github.com/sourcegraph/enterprise/issues/12999
- https://github.com/sourcegraph/enterprise/issues/12718
- https://github.com/sourcegraph/sourcegraph/issues/657
Customers (not exhaustive):