Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot access Azure DevOps git repo with space in project name #2867

Open
abeyerpath opened this issue Mar 20, 2019 · 7 comments

Comments

Projects
None yet
6 participants
@abeyerpath
Copy link

commented Mar 20, 2019

  • Sourcegraph version: 3.2.0
  • Platform information: Ubunutu 18.04 Docker 18.06.1-ce

Steps to reproduce:

  1. Use "Single Git repositories" external service to configure access to Azure DevOps git repos via ssh
  2. Add project/repo path containing a space
{
  "url": "ssh://MyOrg@vs-ssh.visualstudio.com/v3/MyOrg/",

  "repos": [
    "Project1/RepoName",
    "Project 2/AnotherRepo"
  ]
}

Expected behavior:

Both repos available in sourcegraph

Actual behavior:

Both repos clone and index, become available for search and will generate search results.

"Project1/RepoName" works correctly. However for "Project 2/AnotherRepo", with a space in project name, all links to blob paths for individual files/folders as well as the repo settings page give "Repository not found" errors.

@keegancsmith

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

Both repos clone and index, become available for search and will generate search results.

Given that, I don't think this is an error in gitserver / repo-updater. More than likely it is something wrong in the frontend or possibly the graphqlbackend. @attfarhan I think you are the best to investigate since you are modifying the frontend search code as is.

@sqs sqs added this to the Backlog milestone Apr 16, 2019

@sqs sqs added bug search labels Apr 16, 2019

@Jamesits

This comment has been minimized.

Copy link

commented Apr 26, 2019

I can confirm this bug with a similar config. Tried space character in project name or use %20, the result is the same.

@sqs

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

Thank you for reporting. To help us understand priority, is using spaces in repo names a common thing in Azure DevOps? @Jamesits Are you also using Azure DevOps?

@abeyerpath

This comment has been minimized.

Copy link
Author

commented Apr 26, 2019

As a educated guess...I'd suspect that "human friendly" naming is probably more common on AzDO than other environments simply because it's sort of the hosted next-gen version of TFS, which was traditionally very UI driven and thus probably tended to give less thought to making naming schemes URL/machine friendly. There also isn't any immediate feedback when naming a project to discourage doing so.
That said, I have limited experience with either TFS or AzDO outside my current organization, so not sure how prevalent this actually is.
Edit: Also, worth noting that it's at the project level name that this bit me. AzDO allows multiple repos under a project, and I believe our individual repo names are all URL-clean but the project structure was probably set up by a project manager who didn't think to do so.

@Jamesits

This comment has been minimized.

Copy link

commented Apr 26, 2019

Yes I’m using Azure DevOps

@Jamesits

This comment has been minimized.

Copy link

commented Apr 29, 2019

I did some experiments with space in either project name or repo name, in both cases, sourcegraph will return 404 when trying to view files. Search is not impacted by this. I guess there are some double/iterative URL decode issues happening somewhere.

Note that Azure DevOps git URL looks like https://dev.azure.com/{org}/{project}/_git/{repo}, and you can have spaces in both project name and repo name.

@keegancsmith

This comment has been minimized.

Copy link
Member

commented Apr 30, 2019

We need to triage this and determine where this is breaking down in our product. @attfarhan can you own reproducing this and finding the exact requests which are failing? And then look at the trace to see what is passed to the DB for the lookup. I took a quick look since I thought it may be a problem in our URL routing, but the regexes don't seem to care: https://sourcegraph.com/github.com/sourcegraph/sourcegraph@a1962efd66971aa9a26161e7469e58e7c82a8889/-/blob/pkg/routevar/repo.go#L29:2

I think the guess that we may be passing URL escaped strings to the DB is likely the best bet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.