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

Add reindex trigger to repo settings #3796

Closed
mqudsi opened this issue Apr 14, 2018 · 10 comments · Fixed by #17494
Closed

Add reindex trigger to repo settings #3796

mqudsi opened this issue Apr 14, 2018 · 10 comments · Fixed by #17494
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@mqudsi
Copy link
Contributor

mqudsi commented Apr 14, 2018

In a perfect world it wouldn't be necessary, but there are bugs that cause the gitea db to become out of sync with the actual on-disk repo.

Please consider adding a "perform re-index operation" button to the repo settings, so that one can forcibly resync the UI with the repo. For example, I should be able to use it to correct the aftermath of #3795

@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Apr 15, 2018
@mqudsi
Copy link
Contributor Author

mqudsi commented Aug 28, 2018

Until this is resolved, can someone tell me how to manually force the reindexing?

@lunny
Copy link
Member

lunny commented Aug 28, 2018

@mqudsi check the code

return nil, nil

I think it will be reindex when you

  1. stop gitea
  2. delete index data directory
  3. start gitea

@mqudsi
Copy link
Contributor Author

mqudsi commented Feb 14, 2020

@lunny are you talking about the bleve files in the various indexers directories? Those appear to specifically be full-text indices and don't result in the UI data being reloaded.

@jvrsantacruz
Copy link

+1 I have an use case for having already existing repositories and being able to make gitea acknowledge them.

Those repositories follow the same structure as the repositories that gitea owns but are created/updated by a separated replication service.

@miccze
Copy link

miccze commented Apr 9, 2021

I'm also in need of button for reindex trigger. Restarting gitea helps partially, some terms are not being found in code search after restart.

@ForestJohnson
Copy link
Contributor

I want this too. Deleting the /data/gitea/indexers/repos.bleve folder and then restarting does seem to do something but still not all of my repos are indexed. Look here:

https://github.com/go-gitea/gitea/blob/main/modules/indexer/code/indexer.go#L318

pageSize = 50 hardcoded 👀

I'm not sure but it looks like it only ever indexes the 1st 50 repos it finds ?

This has to be an accidental bug right?

Please note there is also a trace log which we can use to watch the re-index process in theory:
https://github.com/go-gitea/gitea/blob/release/v1.15/modules/indexer/code/indexer.go#L148

I will post again if I ever figure out why its not indexing my repos.

@ForestJohnson
Copy link
Contributor

For now I was able to get it to re-index the repo I wanted simply by making a commit on that repo. But it would be nice if the re-index button was added to the admin panel, and also it would be nice if the re-index worked for all repos, not just some of them.

zeripath added a commit to zeripath/gitea that referenced this issue Oct 31, 2021
This PR adds reindexing request buttons to the repository settings page.

Fix go-gitea#3796

Signed-off-by: Andrew Thornton <art27@cantab.net>
@viceice
Copy link
Contributor

viceice commented Dec 8, 2021

Would be nice to be able to force a full re-index via gitea cli.

currently struggling with this error:

Unable to initialize the elasticsearch Repository Indexer connstr: http://opensearch-master:9200 Error: elastic: Error 400 (Bad Request): Invalid alias name [gitea_codes], an index exists with the same name as the alias [type=invalid_alias_name_exception]

@ForestJohnson
Copy link
Contributor

ElasticSearch has an index alias feature which works sort of like an alias file on a computer (sometimes called a soft link). When an ElasticSearch client issues a search request to a cluster, it passes the name of the index it would like to search as a part of the request. That name must match either the name of an index or the name of an alias. You can't have two indexes with the same name, and you also can't have an alias with the same name as an index. Otherwise the ElasticSearch cluster wouldn't know which one you were trying to search; it's a unique ID.

In this case it looks like your elasticsearch cluster was previously set up (perhaps by a previous version of gitea??) to use an index called gitea_codes, but now gitea is trying to create a new alias with the same name gitea_codes, which is not allowed. It's like the same error when you try to sign up for a web site and they tell you

That username is already taken by another user

Maybe you should take a backup of whats in your elasticsearch right now and then completely reset it, delete all the indexes and aliases by hand.

@viceice
Copy link
Contributor

viceice commented Dec 8, 2021

@ForestJohnson Yes, I've manually deleted the three gitea indexes and restarted gitea. Now it's working fine again.

lunny added a commit that referenced this issue Dec 16, 2021
This PR adds reindexing request buttons to the repository settings page.

Fix #3796

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Chianina pushed a commit to Chianina/gitea that referenced this issue Mar 28, 2022
This PR adds reindexing request buttons to the repository settings page.

Fix go-gitea#3796

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants