Sourcegraph #2374

New Issue

GiteaMirror · 2025-11-02T04:34:08-06:00

GiteaMirror commented

2025-11-02 04:34:08 -06:00

Originally created by @ShalokShalom on GitHub (Oct 3, 2018).

Potential new implementation

https://github.com/sourcegraph/sourcegraph

Originally created by @ShalokShalom on GitHub (Oct 3, 2018). Potential new implementation https://github.com/sourcegraph/sourcegraph

GiteaMirror added the type/feature label 2025-11-02 04:34:08 -06:00

GiteaMirror closed this issue

2025-11-02 04:34:08 -06:00

GiteaMirror commented

2025-11-02 04:34:09 -06:00

@jonasfranz commented on GitHub (Oct 5, 2018):

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

@jonasfranz commented on GitHub (Oct 5, 2018): Could you please explain what you want to add to gitea?

GiteaMirror commented

2025-11-02 04:34:09 -06:00

@lunny commented on GitHub (Oct 5, 2018):

Integration with sourcegraph maybe a good idea.

@lunny commented on GitHub (Oct 5, 2018): Integration with sourcegraph maybe a good idea.

GiteaMirror commented

2025-11-02 04:34:09 -06:00

@thomas-mc-work commented on GitHub (Oct 8, 2018):

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

@thomas-mc-work commented on GitHub (Oct 8, 2018): [They are collaborating with gitlab to create an integration](https://gitlab.com/gitlab-org/gitlab-ce/issues/41925). Maybe they'll want to support gitea as well!

GiteaMirror commented

2025-11-02 04:34:09 -06:00

@ijsnow commented on GitHub (Oct 8, 2018):

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 commented on GitHub (Oct 8, 2018): Hello! I work on integration at Sourcegraph. Someone kindly opened [an issue](https://github.com/sourcegraph/browser-extensions/issues/236) on our [browser extension](https://github.com/sourcegraph/browser-extensions) repository asking for an integration. [As I said in that issue](https://github.com/sourcegraph/browser-extensions/issues/236#issuecomment-427940780), 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!

GiteaMirror commented

2025-11-02 04:34:09 -06:00

@lafriks commented on GitHub (Oct 8, 2018):

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

@lafriks commented on GitHub (Oct 8, 2018): @ijsnow is there any integration documentation or any description on how such integration would work? What should be done on Gitea side?

GiteaMirror commented

2025-11-02 04:34:10 -06:00

@ijsnow commented on GitHub (Oct 8, 2018):

After writing my initial comment above, I’ve 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’t 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’t 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:

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

@ijsnow commented on GitHub (Oct 8, 2018): After writing my initial comment above, I’ve 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’t 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](https://github.com/sourcegraph/sourcegraph/tree/master/client/browser) 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](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@master/-/blob/client/browser/src/libs/code_intelligence/code_intelligence.tsx#L97:18). The complexity of the interface varies on the specific code host. GitLab's is pretty simple, [you can see it here.](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@master/-/blob/client/browser/src/libs/gitlab/code_intelligence.ts#L93:14) I haven’t used Gitea personally but after a quick tour through [the example instance](https://try.gitea.io/) 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

GiteaMirror commented

2025-11-02 04:34:10 -06:00

@lunny commented on GitHub (Oct 9, 2018):

@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.

@lunny commented on GitHub (Oct 9, 2018): @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](https://github.com/sourcegraph/browser-extensions).

GiteaMirror commented

2025-11-02 04:34:10 -06:00

@ijsnow commented on GitHub (Oct 9, 2018):

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.

@ijsnow commented on GitHub (Oct 9, 2018): 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](https://github.com/sourcegraph/sourcegraph/issues/343) in Sourcegraph's repository to track this. You can see how we do it for other code hosts [here.](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@1d7722a5295141024f3d2b0e32be790a04827112/-/tree/cmd/repo-updater/repos) We would really appreciate help with this! And I can work on the changes to the typescript code.

GiteaMirror commented

2025-11-02 04:34:10 -06:00

@ShalokShalom commented on GitHub (Nov 23, 2018):

Thanks +1

@ShalokShalom commented on GitHub (Nov 23, 2018): Thanks +1

GiteaMirror referenced this issue

2025-11-02 12:09:03 -06:00

[PR #2374] [MERGED] Fix integration test after librejs location change #16370

Sign in to join this conversation.