Wrong URL when opening file on Sourcegraph web using the JetBrains plugin

[taras-yemets]

Reported by https://github.com/sourcegraph/accounts/issues/6716

• • Platform information: Sourcegraph for JetBrains 2.1.2

Steps to reproduce:

1. Open the file from the Perforce repo in JetBrains IDE.
2. Ensure Sourcegraph plugin is installed and configured (README).
3. Open Sourcegraph plugin context menu and click "Open selection in Sourcegraph web".

More context can be found in this Slack thread.

Expected behavior:

The file is opened on a connected Sourcegraph instance with proper query params (revision, line, etc.).

Actual behavior:

The link navigates to the file not found page on a connected Sourcegraph instance.

If you would like immediate help on this, please email [email protected] (you can still create the issue, but there are no SLAs on issues like there are for support requests).

[peterguy]

Does this have any overlap with #42294?

[vdavid]

• Added the customer-specific infos here: https://github.com/sourcegraph/customer/issues/2146

[vdavid]

@peterguy: they have no overlap.

• https://github.com/sourcegraph/sourcegraph/issues/42294, is about the situation when one uses the "Find with Sourcegraph" dialog (the one that opens for Option+S), finds a file, then chooses to open the file for editing. In this case, we try to match the file found on Sourcegraph (which only exists in memory) to a local file (which exists on the disk). The benefit of doing this successfully is, of course, that you can make changes to the file and eventually commit it. This is what doesn't always work with Perforce now.
• This current issue is for the case when you have a local file open in your IDE, and you want to open this file on Sourcegraph web, typically for sharing the link with a colleague. This is another thing that doesn't work well with some Perforce setups.

[taras-yemets]

@vdavid, @philipp-spiess, and I looked into this issue. Here are some findings.

The repo on the user’s system is coming from a GHE code host (is a Git repository), but that code is cloned over from Perforce using some proprietary tooling. However, Sourcegraph instance only has Perforce code cloned via p4-fusion (original message).
Thus the version control system defined by getRemoteRepoURL is VCSType.GIT and is handled respectively. This remote repo URL is used to build an editor file URL. It is later used redirected according to the logic defined in editor.go.
As the Sourcegraph instance knows nothing about this Git repo (it knows only about the Perforce one the Git repo has been cloned from), the user is expectedly navigated to the repo not found page (Git repo doesn't exist on the Sourcegraph instance).

There is a possibility to configure remote URL replacements. Still, it's not going to work with the current logic of opening/copying Sourcegraph URL from IDE (building the editor URL in the IDE plugin and then opening file redirect) as RepoSourceCloneURLToRepoName function currently doesn't support Perforce code host.

Possible solutions we could think of:

1. Add another plugin configuration field to the JetBrains plugin defining repo name configurations. If the project opened in IDE matches the pattern from this new field value, we build the actual link to a file on Sourcegraph instance (e.g. similar to toBlobAbsoluteURL) on the plugin side (but not the editor file URL). In this way we can skip the mentioned open file redirect logic which currently doesn't support Perforce. Keep the repo remote URL replacements logic as it is.
2. Do not add a new config field and use the existing logic for repo remote URL replacements. Build the actual link to a file on Sourcegraph instance (e.g. similar to toBlobAbsoluteURL) on the plugin side. In this case, we do not depend on openFileRedirect logic.
3. Do not change the plugin code, but add Perforce support to RepoSourceCloneURLToRepoName.

[taylorsperry]

@taras-yemets Do you know if this is still an issue? Sounds like it's related to the "search" component of the JB Search + Cody plugin.

[taras-yemets]

@taras-yemets Do you know if this is still an issue? Sounds like it's related to the "search" component of the JB Search + Cody plugin.

@taylorsperry, yes, this is JB Search + Cody plugin issue and it's still relevant.