doc-locale/fr-fr/integration/zoekt/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
index_code_with_zoekt et search_code_with_zoekt. Désactivés par défaut.zoekt_cross_namespace_search. Désactivés par défaut.index_code_with_zoekt et search_code_with_zoekt ont été supprimés dans GitLab 17.1.zoekt_rollout_worker a été ajouté dans GitLab 17.9. Désactivés par défaut.zoekt_cross_namespace_search et zoekt_rollout_worker ont été supprimés dans GitLab 18.7.{{< /history >}}
[!warning] Cette fonctionnalité est en disponibilité limitée. Pour plus d'informations, consultez l'epic 9404. Donnez votre avis dans le ticket 420920.
Zoekt est un moteur de recherche open source conçu spécifiquement pour la recherche de code.
Grâce à cette intégration, vous pouvez utiliser la recherche de code exacte plutôt que la recherche avancée pour rechercher du code dans GitLab. Vous pouvez utiliser les modes de correspondance exacte et d'expression régulière pour rechercher du code dans un groupe ou un dépôt.
[!note] Zoekt gère uniquement la recherche de code et ne remplace pas Elasticsearch ou OpenSearch. Pour toutes les autres portées de recherche, notamment les commentaires, les commits, les epics, les tickets, les merge requests, les jalons, les projets, les utilisateurs et les wikis, Elasticsearch ou OpenSearch est toujours requis.
Chaque version de GitLab est fournie avec une version spécifique de gitlab-zoekt-indexer et une version du chart gitlab-zoekt.
| Version de GitLab | Version de gitlab-zoekt-indexer | Version du chart gitlab-zoekt |
|---|---|---|
| 19.1 | 1.16.1 | 4.1.0 |
| 19.0 | 1.14.2 | 4.0.0 |
| 18.11 | 1.13.1 | 3.11.0 |
| 18.10 | 1.11.2 | 3.10.0 |
| 18.9 | 1.8.2 | 3.9.0 |
| 18.8 | 1.8.0 | 3.8.0 |
| 18.6 et 18.7 | 1.7.6 | 3.7.1 |
Prérequis :
Pour activer la recherche de code exacte dans GitLab, vous devez avoir au moins un nœud Zoekt connecté à l'instance. Les méthodes d'installation suivantes sont prises en charge pour Zoekt :
gitlab-zoekt.install=true)Les méthodes d'installation suivantes sont disponibles à des fins de test uniquement et non pour une utilisation en production :
Prérequis :
Pour activer la recherche de code exacte depuis l'interface utilisateur de GitLab :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez gérer la recherche de code exacte avec des tâches Rake.
Pour activer l'indexation et la recherche, exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:index
Cette tâche active zoekt_indexing_enabled, zoekt_search_enabled et zoekt_auto_index_root_namespace. RolloutWorker indexe automatiquement tous les espaces de nommage racines, et la recherche devient disponible lorsque les index sont prêts.
Pour désactiver l'indexation et la recherche, exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:disable
Cette tâche désactive à la fois zoekt_indexing_enabled et zoekt_search_enabled.
Pour mettre en pause l'indexation (par exemple, pendant la maintenance), exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:pause_indexing
Pour reprendre l'indexation, exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:resume_indexing
Pour estimer le stockage requis pour vos nœuds Zoekt, exécutez cette tâche Rake :
sudo gitlab-rake gitlab:zoekt:estimate_storage
Pour plus d'informations, consultez Estimer les besoins en stockage.
{{< history >}}
{{< /history >}}
Pour réessayer l'indexation de tous les enregistrements de dépôts Zoekt à l'état failed, exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:reindex_failed_projects
Cette tâche fait passer tous les enregistrements failed zoekt_repository à l'état pending avec retries_left défini sur 1, afin qu'ils soient récupérés lors du prochain cycle d'indexation.
Pour réessayer uniquement des projets spécifiques, transmettez une liste d'identifiants de projet séparés par des virgules :
gitlab-rake "gitlab:zoekt:reindex_failed_projects[1,2,3]"
{{< history >}}
zoekt_critical_watermark_stop_indexing. Désactivés par défaut.zoekt_critical_watermark_stop_indexing a été supprimé.{{< /history >}}
Prérequis :
Les performances d'indexation dépendent des limites de CPU et de mémoire sur les nœuds de l'indexeur Zoekt. Pour vérifier le statut d'indexation :
{{< tabs >}}
{{< tab title="GitLab 17.10 et versions ultérieures" >}}
Exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:info
Pour actualiser automatiquement les données toutes les 10 secondes, exécutez plutôt cette tâche Rake :
gitlab-rake "gitlab:zoekt:info[10]"
{{< /tab >}}
{{< tab title="GitLab 17.9 et versions antérieures" >}}
Dans une console Rails, exécutez ces commandes :
Search::Zoekt::Index.group(:state).count
Search::Zoekt::Repository.group(:state).count
Search::Zoekt::Task.group(:state).count
{{< /tab >}}
{{< /tabs >}}
La tâche Rake gitlab:zoekt:info renvoie une sortie similaire à la suivante :
Exact Code Search
GitLab version: 19.1.0
Enable indexing: yes
Enable searching: yes
Pause indexing: no
Index root namespaces automatically: yes
Cache search results for five minutes: yes
Indexing CPU to tasks multiplier: 1.0
Probability of random force reindexing (percentage): 0.25
Number of parallel processes per indexing task: 1
Number of namespaces per indexing rollout: 32
Offline nodes automatically deleted after: 20m
Indexing timeout per project: 30m
Maximum number of files per project to be indexed: 500000
Maximum file size for indexing: 1MB
Maximum trigrams per file: 20000
Retry interval for failed namespaces: 1d
Number of replicas per namespace: 1
Maximum number of projects for legacy search: 1000
Maximum number of process restarts within 15 minutes for nodes: 3
Nodes
# Number of Zoekt nodes and their status
Node count: 2 (online: 2, offline: 0)
Last seen at: 2026-04-16 22:58:09 UTC (less than a minute ago)
Max schema_version: 2601
Storage reserved / usable: 71.1 MiB / 124 GiB (0.06%)
Storage indexed / reserved: 42.7 MiB / 71.1 MiB (60.0%)
Storage used / total: 797 GiB / 921 GiB (86.54%)
Online node watermark levels: 2
- low: 2
Indexing status
Group count: 8
# Number of enabled namespaces and their status
EnabledNamespace count: 8 (without indices: 0, rollout blocked: 0, with search disabled: 0)
Replicas count: 8
- ready: 8
Indices count: 8
- ready: 8
Indices watermark levels: 8
- healthy: 8
Repositories count: 10
- ready: 10
Tasks count: 10
- done: 10
Tasks pending/processing by type: (none)
Storage buffer factor: 0.831× [dynamic (observed)]
Feature Flags (Non-Default Values)
Feature flags: none
Feature Flags (Default Values)
Feature flags: none
Node Details
Node 1 - test-zoekt-hostname-1:
Status: Online
Last seen at: 2026-04-16 22:58:09 UTC (less than a minute ago)
Disk utilization: 86.54%
Unclaimed storage: 62 GiB
# Zoekt build version on the node. Must match GitLab version.
Zoekt version: 2026.04.15-v1.4.0-1-g89a8871
Schema version: 2601
Node 2 - test-zoekt-hostname-2:
Status: Online
Last seen at: 2026-04-16 22:58:09 UTC (less than a minute ago)
Disk utilization: 86.54%
Unclaimed storage: 62 GiB
Zoekt version: 2026.04.15-v1.4.0-1-g89a8871
Schema version: 2601
{{< history >}}
{{< /history >}}
Prérequis :
Effectuez un bilan de santé pour comprendre le statut de votre infrastructure Zoekt, notamment :
Pour effectuer un bilan de santé, exécutez la tâche suivante :
gitlab-rake gitlab:zoekt:health
Cette tâche fournit :
HEALTHY, DEGRADED ou UNHEALTHY0=healthy, 1=degraded ou 2=unhealthyPour exécuter automatiquement des bilans de santé toutes les 10 secondes, exécutez la tâche suivante :
gitlab-rake "gitlab:zoekt:health[10]"
La sortie inclut des indicateurs de statut colorés et affiche :
HEALTHY, DEGRADED ou UNHEALTHY{{< history >}}
{{< /history >}}
Prérequis :
Pour forcer la réindexation d'une plage de projets, exécutez cette tâche Rake :
gitlab-rake gitlab:zoekt:reindex_projects ID_FROM=10 ID_TO=20
ID_FROM et ID_TO représentent la plage d'identifiants de projet.
Pour forcer la réindexation d'un seul projet, utilisez la même valeur pour ID_FROM et ID_TO. Pour forcer la réindexation de tous les projets, n'utilisez pas ces variables d'environnement.
Prérequis :
Pour mettre en pause l'indexation pour la recherche de code exacte :
Lorsque vous mettez en pause l'indexation pour la recherche de code exacte, toutes les modifications apportées à votre dépôt sont mises en file d'attente. Pour reprendre l'indexation, décochez la case Pause indexing for exact code search.
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez indexer automatiquement les espaces de nommage racines existants et nouveaux. Pour indexer automatiquement tous les espaces de nommage racines :
Lorsque vous activez ce paramètre, GitLab crée des tâches d'indexation pour tous les projets dans :
Une fois un projet indexé, GitLab ne crée qu'une indexation incrémentielle lorsqu'une modification du dépôt est détectée.
Lorsque vous désactivez ce paramètre :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez mettre en cache les résultats de recherche pour de meilleures performances. Cette fonctionnalité est activée par défaut et met en cache les résultats pendant cinq minutes.
Pour mettre en cache les résultats de recherche :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre de tâches d'indexation simultanées pour un nœud Zoekt par rapport à sa capacité CPU.
Un multiplicateur plus élevé signifie que davantage de tâches peuvent s'exécuter simultanément, ce qui améliore le débit d'indexation au prix d'une utilisation accrue du CPU. La valeur par défaut est 1.0 (une tâche par cœur CPU).
Vous pouvez ajuster cette valeur en fonction des performances et de la charge de travail du nœud. Pour définir le nombre de tâches d'indexation simultanées :
Dans le coin supérieur droit, sélectionnez Admin
Dans la barre latérale gauche, sélectionnez Paramètres > Rechercher
Développez Recherche de code spécifique
Dans le champ de texte Indexation du processeur sur le multiplicateur de tâches, saisissez une valeur.
Par exemple, si un nœud Zoekt dispose de 4 cœurs CPU et que le multiplicateur est 1.5, le nombre de tâches simultanées pour le nœud est 6.
Sélectionnez Enregistrer les modifications
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir la probabilité qu'un projet soit réindexé de force au lieu d'être indexé de manière incrémentielle. La valeur par défaut est 0.25 (0,25 %).
La réindexation forcée aide à éviter l'épuisement des gestionnaires de mappage mémoire (mmap) en reconstruisant périodiquement les index depuis zéro. Un pourcentage plus élevé augmente la charge d'indexation, en particulier pour les très grands dépôts.
Pour définir la probabilité de réindexation forcée aléatoire :
0 et 100{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre de processus parallèles par tâche d'indexation.
Un nombre plus élevé améliore le temps d'indexation au prix d'une utilisation accrue du CPU et de la mémoire. La valeur par défaut est 1 (un processus par tâche d'indexation).
Vous pouvez ajuster cette valeur en fonction des performances et de la charge de travail du nœud. Pour définir le nombre de processus parallèles par tâche d'indexation :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre d'espaces de nommage par job RolloutWorker pour l'indexation initiale. La valeur par défaut est 32. Vous pouvez ajuster cette valeur en fonction des performances et de la charge de travail du nœud.
Pour définir le nombre d'espaces de nommage par déploiement d'indexation :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez supprimer automatiquement les nœuds Zoekt hors ligne après une période spécifique, ainsi que leurs index, dépôts et tâches associés. La valeur par défaut est 12h (12 heures).
Utilisez ce paramètre pour gérer votre infrastructure Zoekt et éviter les ressources orphelines. Pour définir quand les nœuds hors ligne sont automatiquement supprimés :
30m (30 minutes), 2h (deux heures) ou 1d (un jour). Pour désactiver la suppression automatique, définissez la valeur sur 0{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le délai d'indexation pour un projet. La valeur par défaut est 30m (30 minutes).
Pour définir le délai d'indexation pour un projet :
30m (30 minutes), 2h (deux heures) ou 1d (un jour){{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre maximal de fichiers dans un projet pouvant être indexés. Les projets comportant plus de fichiers que cette limite sur la branche par défaut ne sont pas indexés. La valeur par défaut est 500,000.
Vous pouvez ajuster cette valeur en fonction des performances et de la charge de travail du nœud. Pour définir le nombre maximal de fichiers dans un projet à indexer :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir la taille maximale d'un fichier à indexer. La valeur par défaut est 1MB.
Pour les fichiers dépassant la taille spécifiée, seuls les noms de fichiers sont indexés. Vous pouvez rechercher ces fichiers uniquement par nom de fichier.
Pour définir la taille maximale des fichiers pour l'indexation :
512B, 50KB, 2MB ou 1GB). La valeur peut également être en minuscules{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre maximal de trigrammes pour qu'un fichier soit indexé. La valeur par défaut est 20,000.
Les trigrammes sont des séquences de trois caractères que Zoekt utilise pour une recherche de code efficace. Pour les fichiers dépassant cette limite de trigrammes, seuls les noms de fichiers sont indexés. Une limite plus élevée affecte à la fois les performances d'indexation et de recherche.
Pour définir le nombre maximal de trigrammes pour l'indexation :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir l'intervalle de nouvelle tentative pour les espaces de nommage ayant précédemment échoué. La valeur par défaut est 1d (un jour). Une valeur de 0 signifie que les espaces de nommage ayant échoué ne feront jamais de nouvelle tentative.
Pour définir l'intervalle de nouvelle tentative pour les espaces de nommage ayant échoué :
30m (30 minutes), 2h (deux heures) ou 1d (un jour){{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre de réplicas par espace de nommage. La valeur par défaut est 1 (un réplica par espace de nommage).
Augmenter le nombre de réplicas par espace de nommage améliore la disponibilité de la recherche en répartissant la charge sur plusieurs nœuds Zoekt. Un plus grand nombre de réplicas augmente les besoins en stockage.
Pour définir le nombre de réplicas par espace de nommage :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre maximal de projets à rechercher dans un groupe lorsque l'indexation par identifiant de traversée est encore en cours. La valeur par défaut est 1,000.
Lorsque vous effectuez une recherche dans un groupe avant que l'indexation par identifiant de traversée soit terminée, GitLab recherche uniquement les premiers projets (par identifiant de projet) jusqu'à cette limite et affiche un avertissement indiquant que certains projets ne sont pas inclus dans les résultats. Une fois l'indexation par identifiant de traversée terminée, GitLab recherche dans tous les projets du groupe.
Pour définir le nombre maximal de projets pour la recherche dans les anciennes versions :
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez définir le nombre maximal de redémarrages de processus en l'espace de 15 minutes avant qu'un nœud soit exclu du routage de recherche. La valeur par défaut est 2.
GitLab utilise ce paramètre pour détecter les processus d'indexeur ou de serveur web en boucle de plantage. Lorsqu'un nœud dépasse le nombre de redémarrages de processus en l'espace de 15 minutes, il est exclu de la recherche jusqu'à ce que le nombre de redémarrages revienne dans la plage. Une valeur de 0 signifie que le nœud est exclu après un seul redémarrage.
Si tous les nœuds en ligne sont exclus, GitLab bascule sur l'ensemble complet des nœuds en ligne pour éviter une interruption de la recherche.
Pour définir le nombre maximal de redémarrages de processus pour les nœuds :
{{< history >}}
{{< /history >}}
Prérequis :
Pour exécuter Zoekt sur un serveur différent de GitLab :
Les recommandations suivantes peuvent être sur-provisionnées pour certains déploiements. Vous devez surveiller votre déploiement pour vous assurer que :
Ajustez les ressources en fonction des caractéristiques spécifiques de votre charge de travail, notamment :
Le serveur web et l'indexeur ont des modèles d'utilisation de la mémoire différents.
Le serveur web mappe en mémoire les fragments d'index depuis le disque vers la mémoire virtuelle. Le système d'exploitation transfère les données des fragments depuis et vers la mémoire physique au fil des recherches. L'utilisation de la mémoire résidente augmente avec l'ensemble de travail actif. Les nœuds avec des index plus grands ou un volume de requêtes plus élevé nécessitent davantage de mémoire pour le serveur web afin d'éviter l'écroulement des pages et les situations de mémoire insuffisante.
Lorsque l'indexeur construit ou reconstruit des index, il traite les données d'objets Git en mémoire. L'utilisation de la mémoire augmente brusquement lors de l'indexation de grands dépôts ou lorsque plusieurs tâches s'exécutent en parallèle. Vous pouvez contrôler la mémoire maximale de l'indexeur en ajustant le nombre de processus parallèles par tâche d'indexation et de tâches d'indexation simultanées.
Dans les déploiements sur VM et sur serveur physique, le serveur web et l'indexeur partagent la même mémoire système.
Pour des performances optimales, le dimensionnement approprié des nœuds Zoekt est crucial. Les recommandations de dimensionnement diffèrent entre les déploiements Kubernetes et VM en raison de la façon dont les ressources sont allouées et gérées.
Le tableau suivant présente les ressources recommandées par nœud (par pod StatefulSet) pour les déploiements Kubernetes en fonction des besoins en stockage d'index. Chaque pod du StatefulSet exécute ses propres conteneurs de serveur web et d'indexeur avec des allocations de ressources indépendantes et son propre volume persistant pour le stockage des index. Si vous exécutez plusieurs nœuds, multipliez ces ressources par le nombre de nœuds pour calculer les ressources totales du cluster.
| Disque | CPU du serveur web | Mémoire du serveur web | CPU de l'indexeur | Mémoire de l'indexeur |
|---|---|---|---|---|
| 128 Go | 1 | 16 Gio | 1 | 6 Gio |
| 256 Go | 1,5 | 32 Gio | 1 | 8 Gio |
| 512 Go | 2 | 64 Gio | 1 | 12 Gio |
| 1 To | 3 | 128 Gio | 1,5 | 24 Gio |
| 2 To | 4 | 256 Gio | 2 | 32 Gio |
Pour gérer les ressources de manière plus granulaire, vous pouvez allouer le CPU et la mémoire séparément à différents conteneurs.
Pour les déploiements Kubernetes :
pd-balanced sur GCP, ce qui équilibre les performances et les coûts. Les options équivalentes incluent gp3 sur AWS et Premium_LRS sur Azure.Le tableau suivant présente les ressources recommandées par nœud pour les déploiements sur VM et sur serveur physique en fonction des besoins en stockage d'index. Si vous exécutez plusieurs nœuds, multipliez ces ressources par le nombre de nœuds pour calculer les ressources totales du cluster.
| Disque | Taille de la VM | CPU total | Mémoire totale | AWS | GCP | Azure |
|---|---|---|---|---|---|---|
| 128 Go | Small | 2 cœurs | 16 Go | r5.large | n1-highmem-2 | Standard_E2s_v3 |
| 256 Go | Moyen | 4 cœurs | 32 Go | r5.xlarge | n1-highmem-4 | Standard_E4s_v3 |
| 512 Go | Large | 4 cœurs | 64 Go | r5.2xlarge | n1-highmem-8 | Standard_E8s_v3 |
| 1 To | X-Large | 8 cœurs | 128 Go | r5.4xlarge | n1-highmem-16 | Standard_E16s_v3 |
| 2 To | 2X-Large | 16 cœurs | 256 Go | r5.8xlarge | n1-highmem-32 | Standard_E32s_v3 |
Vous pouvez allouer ces ressources uniquement à l'ensemble du nœud.
Pour les déploiements sur VM et sur serveur physique :
Les besoins en stockage de Zoekt dépendent de la taille de vos dépôts Git et de votre configuration de réplicas. Zoekt indexe uniquement les données d'objets Git (code source et historique des commits). Il n'indexe pas les fichiers LFS, les artefacts CI/CD, les paquets, les wikis ni les autres composants de stockage.
Pour estimer les besoins en stockage, exécutez cette tâche Rake :
sudo gitlab-rake gitlab:zoekt:estimate_storage
Cette tâche interroge votre base de données GitLab et génère une estimation du stockage basée sur les tailles actuelles de vos dépôts et votre configuration de réplicas.
Pour calculer manuellement les besoins en stockage, utilisez plutôt ces formules :
storage_per_replica = sum(repository_git_size) × buffer_factor
total_cluster_storage = storage_per_replica × number_of_replicas
repository_git_size est la taille des objets Git pour chaque dépôt. Cette valeur n'inclut pas les objets LFS, les wikis, les artefacts ni les paquets. buffer_factor est la marge disponible lors de l'indexation initiale. Vous pouvez calculer cette valeur avec Search::Zoekt::Index.global_buffer_factor, qui est généralement égale à 3 par défaut.
Pour afficher repository_git_size :
Pour la cible de provisionnement initiale, commencez par trois fois votre total repository_git_size multiplié par le nombre de réplicas. Par exemple :
GitLab réserve cette marge en interne pour s'assurer que Zoekt dispose de suffisamment d'espace lors de l'indexation. Une fois l'indexation initiale terminée, l'utilisation réelle du disque est généralement plus proche de la moitié de repository_git_size d'après les données observées sur GitLab.com. Effectuez une mise à l'échelle verticale ou horizontale uniquement si nécessaire.
Pour afficher le facteur de tampon actuel, exécutez cette tâche Rake :
sudo gitlab-rake gitlab:zoekt:info
La sortie inclut Storage buffer factor, qui affiche la valeur dynamique utilisée par le planificateur.
Pour surveiller le stockage des nœuds Zoekt, consultez vérifier le statut d'indexation. Si les espaces de nommage ne sont pas indexés en raison d'un espace disque insuffisant, ajoutez des nœuds ou augmentez la capacité disque.
Zoekt implémente un système d'authentification multicouche pour sécuriser la communication entre GitLab, l'indexeur Zoekt et les composants du serveur web Zoekt. L'authentification est appliquée sur tous les canaux de communication.
Toutes les méthodes d'authentification utilisent le secret GitLab Shell. Les tentatives d'authentification échouées renvoient des réponses 401 Unauthorized.
L'indexeur Zoekt s'authentifie auprès de GitLab avec des jetons web JSON (JWT) pour récupérer les tâches d'indexation et envoyer des rappels de fin.
Cette méthode utilise .gitlab_shell_secret pour la signature et la vérification. Les jetons sont envoyés dans l'en-tête Gitlab-Shell-Api-Request. Les points de terminaison suivants sont disponibles :
GET /internal/search/zoekt/:uuid/heartbeat pour la récupération des tâchesPOST /internal/search/zoekt/:uuid/callback pour les mises à jour de statutCette méthode assure une interrogation sécurisée pour la distribution des tâches et la notification du statut entre les nœuds de l'indexeur Zoekt et GitLab.
{{< history >}}
{{< /history >}}
GitLab s'authentifie auprès du serveur web Zoekt avec des jetons web JSON (JWT) pour exécuter des requêtes de recherche. Les jetons JWT fournissent une authentification à durée limitée, signée cryptographiquement, cohérente avec les autres modèles d'authentification GitLab.
Cette méthode utilise Gitlab::Shell.secret_token et l'algorithme HS256 (HMAC avec SHA-256). Les jetons sont envoyés dans l'en-tête Authorization: Bearer <jwt_token> et expirent dans cinq minutes pour limiter l'exposition.
Les points de terminaison incluent /webserver/api/search et /webserver/api/v2/search. Les revendications JWT sont l'émetteur (gitlab) et l'audience (gitlab-zoekt).