Federated Advanced Global Search for Self-Managed
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve Related to https://gitlab.com/gitlab-org/gitlab/issues/6468 - specifically, teams may have code that sits across both public and private instances and want a unified search experience for those. ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> GitHub has a product called [GitHub Connect](https://help.github.com/en/enterprise/2.19/user/github/searching-for-information-on-github/enabling-githubcom-repository-search-in-github-enterprise-server) which supports [unified search](https://help.github.com/en/enterprise/2.15/admin/installation/enabling-unified-search-between-github-enterprise-server-and-githubcom) enabling searching from self-managed instances to include results of public and private projects on GitHub.com. Search support is one-way with GitHub in that only .com results can be searched on-prem. On-prem results can't be searched from .com instances. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Some potential ideas have been suggested [here](https://gitlab.com/gitlab-org/gitlab/issues/6468#note_226113172) for search. > Introduce cross server search, by having one instance hit another instance's global search API (Elasticsearch): https://docs.gitlab.com/ee/api/search.html#global-search-api. Initially this could use a single defined user account to perform the search, with the desired level of access (likely minimal), to avoid having to dealing with per-user cross server authentication up front. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> It would be important to understand permissions of users across multiple instances so that results are returned properly. Starting with public only may be a sane default here to prevent needing to comprehensively understand the permissions model in two places. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> Documentation would need to be updated to specify limitations of search across multiple instances (i.e. public/private results, one-way search, etc...).
epic