Recherche gitea #4576

Closed
opened 1 year ago by Bennyb · 11 comments
Bennyb commented 1 year ago
Collaborator

Visiblement la recherche gitea n'est pas opérationelle sur les tickets importéss

Sur la machine de @cy.altern et tofulm ça passe

On cherche à trouver la commande pour réindexer tout le contenu

à voir avec @cam.lafit ... je fais le ticket pour que tout le monde puisse suivre

Visiblement la recherche gitea n'est pas opérationelle sur les tickets importéss Sur la machine de @cy.altern et tofulm ça passe On cherche à trouver la commande pour réindexer tout le contenu à voir avec @cam.lafit ... je fais le ticket pour que tout le monde puisse suivre
b_b commented 1 year ago
Collaborator

Quelques liens à ce sujet :

https://github.com/go-gitea/gitea/issues/16152 & https://discourse.gitea.io/t/cant-search-issues-after-gogs-migration/168/2

Try deleting issues index directory and restart gitea server. Than it will reindex everything

Quelques liens à ce sujet : https://github.com/go-gitea/gitea/issues/16152 & https://discourse.gitea.io/t/cant-search-issues-after-gogs-migration/168/2 > Try deleting issues index directory and restart gitea server. Than it will reindex everything
cy.altern reopened this issue 1 year ago
Collaborator

le lien https://discourse.gitea.io/t/cant-search-issues-after-gogs-migration/168/2 est de bon conseil : je valide le scénario suivant sur notre instance de Gitea

  • clonage de la BDD depuis git.spip.net
  • vérification qu'une recherche sur les tickets récent d'un repo (= qui n'existaient pas avant le clonage) ne donne aucun résultat
  • suppression du répertoire indexers stockant les fichiers d'indexation des tickets = référencés dans la configuration par :
[indexer]
ISSUE_INDEXER_TYPE = bleve
ISSUE_INDEXER_PATH = /var/gitea/spip/data/indexers/issues.bleve
  • restart du gitea.service
  • les fichiers d'indexs sont régénérés quasi instantanément et la recherche retourne des résultats identiques à ceux de l'instance clonée

Reste donc à appliquer cette recette sur le gitea de git.spip.net pour que la recherche fonctionne sur l'ensemble des contenus des tickets :-)

le lien https://discourse.gitea.io/t/cant-search-issues-after-gogs-migration/168/2 est de bon conseil : je valide le scénario suivant sur notre instance de Gitea - clonage de la BDD depuis git.spip.net - vérification qu'une recherche sur les tickets récent d'un repo (= qui n'existaient pas avant le clonage) ne donne aucun résultat - suppression du répertoire `indexers` stockant les fichiers d'indexation des tickets = référencés dans la configuration par : ``` [indexer] ISSUE_INDEXER_TYPE = bleve ISSUE_INDEXER_PATH = /var/gitea/spip/data/indexers/issues.bleve ``` - restart du gitea.service - les fichiers d'indexs sont régénérés quasi instantanément et la recherche retourne des résultats identiques à ceux de l'instance clonée Reste donc à appliquer cette recette sur le gitea de git.spip.net pour que la recherche fonctionne sur l'ensemble des contenus des tickets :-)
Collaborator

Le répertoire indexers de l'instance vient d'être purgé et les services relancés

Le répertoire indexers de l'instance vient d'être purgé et les services relancés
b_b commented 1 year ago
Collaborator

On peut fermer le ticket maintenant ?

On peut fermer le ticket maintenant ?
Collaborator

Hello

Hélas non le test fait avec @cy.altern n'est pas concluant. La recherche n'est pas iso à leur copie.

Hello Hélas non le test fait avec @cy.altern n'est pas concluant. La recherche n'est pas iso à leur copie.
b_b commented 1 year ago
Collaborator

Ha merdum :\

Ha merdum :\
Collaborator

On en est où là dessus ? On sait pourquoi ? C'est vraiment handicapant, surtout pour les tickets du core qui sont des milliers (avec ceux fermés) quand on veut retrouver un ticket et sa discussion.

On en est où là dessus ? On sait pourquoi ? C'est vraiment handicapant, surtout pour les tickets du core qui sont des milliers (avec ceux fermés) quand on veut retrouver un ticket et sa discussion.
Collaborator

puisque "chez nous ça marche®" en solution de secours on pourrait envisager d'ouvrir l'accès à notre clone pour permettre de rechercher dedans : les URLs étant strictement identiques, au sous-domaine initial près, on peut "facilement" revenir sur git.spip à partir des résultats.

Problème : comment éviter que les utilisateurs ne puissent cloner/commiter/commenter/ticketer dessus ?

puisque "chez nous ça marche®" en solution de secours on pourrait envisager d'ouvrir l'accès à notre clone pour permettre de rechercher dedans : les URLs étant strictement identiques, au sous-domaine initial près, on peut "facilement" revenir sur git.spip à partir des résultats. Problème : comment éviter que les utilisateurs ne puissent cloner/commiter/commenter/ticketer dessus ?
b_b commented 1 year ago
Collaborator

Merci pour la proposition @cy.altern mais amha ça n'est pas viable. Vous avez fait le travail sur votre instance et ça fonctionne, le logiciel est le même, ça devrait maintenant fonctionner en prod.

Merci pour la proposition @cy.altern mais amha ça n'est pas viable. Vous avez fait le travail sur votre instance et ça fonctionne, le logiciel est le même, ça devrait maintenant fonctionner en prod.
Collaborator

Hello

@cy_altern @b_b vous auriez un créneau de disponible le 26/10 en après
midi de libre ?
Si oui je me bloque le créneau et on s'y colle pour trouver une solution.

Km

Hello @cy_altern @b_b vous auriez un créneau de disponible le 26/10 en après midi de libre ? Si oui je me bloque le créneau et on s'y colle pour trouver une solution. Km
Collaborator

c'est réglé (petit problème de gestion des "working dir" de gitea en mutualisation)

c'est réglé (petit problème de gestion des "working dir" de gitea en mutualisation)
cy.altern closed this issue 1 year ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.