Gitea: Sourcegraph

Created on 3 Oct 2018  路  9Comments  路  Source: go-gitea/gitea

Potential new implementation

https://github.com/sourcegraph/sourcegraph

kinfeature

Most helpful comment

Integration with sourcegraph maybe a good idea.

All 9 comments

Could you please explain what you want to add to gitea?

Integration with sourcegraph maybe a good idea.

They are collaborating with gitlab to create an integration. Maybe they'll want to support gitea as well!

Hello! I work on integration at Sourcegraph. Someone kindly opened an issue on our browser extension repository asking for an integration. As I said in that issue, we'd gladly add support to the browser extension. A PR from Gitea users would be the quickest way to add support (happy to help/point in the right direction, just ask on the issue). However, we'd prefer to get code intelligence built into Gitea directly so everyone using Gitea can have support out of the box rather than needing to discover our extension.

I'm happy to discuss next steps and collaboration on this!

@ijsnow is there any integration documentation or any description on how such integration would work? What should be done on Gitea side?

After writing my initial comment above, I鈥檝e been doing some thinking and think it would be best to add support through the browser extension. The reason being that there are some open questions in the integration process that we are hoping to hash out with the GitLab collaboration mentioned above. We are hoping to come out of that with a standard way of integrating with code hosts(our name for tools like Gitea, GitLab, etc).

That doesn鈥檛 mean you have to wait for that project to finish to get support. We would gladly add support for Gitea directly into the browser extension while we figure out a more solidified integration process. Still, the quickest route would be for Gitea users to open a PR for us.

For implementing support in the browser extension, I've reduced the amount of work needed to add support in our browser extension to implementing the CodeHost interface. The complexity of the interface varies on the specific code host. GitLab's is pretty simple, you can see it here. I haven鈥檛 used Gitea personally but after a quick tour through the example instance I believe it should be relatively simple.

Essentially we need to find which pages show code and figure out how to get the repo's name, the file path we're looking at and the revision we're at.

Just to be clear, the reasons why we prefer 1st class integration over the browser extension route are as follows:

  1. Distribution: only users who have the browser extension installed benefit
  2. Fragility: browser extensions are inherently fragile due to the reliance on specific DOM structures that can change overtime

@ijsnow I was that someone on your first comment. :( All the maintainers on gitea are familiar with Go better than Typescript. So I think that needs some time for us to make a PR for sourcegraph/browser-extensions.

Well in that case, a good way to start would actually to be able to add support on the backend for cloning and managing repositories Sourcegraph has access to from Gitea. I've opened an issue in Sourcegraph's repository to track this.

You can see how we do it for other code hosts here.

We would really appreciate help with this! And I can work on the changes to the typescript code.

Thanks +1

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ghost picture ghost  路  3Comments

haytona picture haytona  路  3Comments

Fastidious picture Fastidious  路  3Comments

jorise7 picture jorise7  路  3Comments

cookiengineer picture cookiengineer  路  3Comments