I don't know it it works well and is usable. It seem not to be activated on https://try.gitea.io/
Gitea now suports it with elastic search.
https://github.com/go-gitea/gitea/pull/10273
I don't know it it works well and is usable. It seem not to be activated on https://try.gitea.io/
Gitea has had code search for a while, it was just 1.13 that introduced being able to use ES. Codesearch is not available in any form on try.gitea.io as people love to push giant repos to it and eat up all our disk space (hence the notice that repos may disappear at any time), and having codesearch would only increase the resources needed.
Gitea has had code search for a while, it was just 1.13 that introduced being able to use ES. Codesearch is not available in any form on try.gitea.io as people love to push giant repos to it and eat up all our disk space (hence the notice that repos may disappear at any time), and having codesearch would only increase the resources needed.
While I use Gitea codesearch on the daily, for codeberg an alternative could be to set up an install of https://about.sourcegraph.com/ as it is significantly more robust and more featureful. The non-enterprise edition is licensed as Apache 2.
While I use Gitea codesearch on the daily, for codeberg an alternative could be to set up an install of https://about.sourcegraph.com/ as it is significantly more robust and more featureful. The non-enterprise edition is licensed as Apache 2.
I see it as running side-by-side, however to make integration easier I could send a customization PR to codeberg that would swap out the standard code search text box with it opening up results in sourcegraph, and also add a button for something like "open this repo in sourcegraph".
Whichever way is decided (enabling code search via bleve, es, or connecting to a sourcegraph install) will add additional effort for the infra team though, so while one way may be better in terms of accuracy and usability, we should also take into account those managing the infra so as not to cause burnout.
I see it as running side-by-side, however to make integration easier I could send a customization PR to codeberg that would swap out the standard code search text box with it opening up results in sourcegraph, and also add a button for something like "open this repo in sourcegraph".
Whichever way is decided (enabling code search via bleve, es, or connecting to a sourcegraph install) will add additional effort for the infra team though, so while one way may be better in terms of accuracy and usability, we should also take into account those managing the infra so as not to cause burnout.
It would be great to have this feature! It would significantly boost productivity on codeberg for me. I am happy with whatever works best for the devs.
It would be great to have this feature! It would significantly boost productivity on codeberg for me. I am happy with whatever works best for the devs.
@hw sadly I dont have any real-world-data since I didn't hat tested big instances with neither both of them :/
why not just test it with codeberg's test instance and look ow mouch each take?
@ashimokawa can be configured as you wish ...
@hw sadly I dont have any real-world-data since I didn't hat tested big instances with neither both of them :/
why not just test it with codeberg's test instance and look ow mouch each take?
why not just test it with codeberg's test instance and look ow mouch each take?
Running such tests (in a dedicated VM for isolation) is high on the todo list.
> why not just test it with codeberg's test instance and look ow mouch each take?
Running such tests (in a dedicated VM for isolation) is high on the todo list.
Gitea now suports it with elastic search.
https://github.com/go-gitea/gitea/pull/10273
I don't know it it works well and is usable. It seem not to be activated on https://try.gitea.io/
Gitea has had code search for a while, it was just 1.13 that introduced being able to use ES. Codesearch is not available in any form on try.gitea.io as people love to push giant repos to it and eat up all our disk space (hence the notice that repos may disappear at any time), and having codesearch would only increase the resources needed.
While I use Gitea codesearch on the daily, for codeberg an alternative could be to set up an install of https://about.sourcegraph.com/ as it is significantly more robust and more featureful. The non-enterprise edition is licensed as Apache 2.
Interesting, ... do you imagine some kind of integration, or running it side-by-side?
I see it as running side-by-side, however to make integration easier I could send a customization PR to codeberg that would swap out the standard code search text box with it opening up results in sourcegraph, and also add a button for something like "open this repo in sourcegraph".
Whichever way is decided (enabling code search via bleve, es, or connecting to a sourcegraph install) will add additional effort for the infra team though, so while one way may be better in terms of accuracy and usability, we should also take into account those managing the infra so as not to cause burnout.
It would be great to have this feature! It would significantly boost productivity on codeberg for me. I am happy with whatever works best for the devs.
@6543 : do you have any gut feeling how sourcegraph compares to the elasticsearch index in terms of storage requirements?
@techknowlogick
I assume the ES instance could run on a different server, right?
@ashimokawa can be configured as you wish ...
@hw sadly I dont have any real-world-data since I didn't hat tested big instances with neither both of them :/
why not just test it with codeberg's test instance and look ow mouch each take?
Running such tests (in a dedicated VM for isolation) is high on the todo list.