Index namespaces before turning on exact code search

What does this MR do?

The UI steps to enable exact code search select Enable indexing and Enable searching and stop. With only those two selected, no namespace is indexed, and global code search returns no results and no error while group and project code search keep using advanced search. On GitLab 19.4.1 and a 19.5 nightly build, with advanced search on, global code search over REST, GraphQL and the GitLab MCP server's search tool was still empty after six minutes, and on 19.4.1 the UI showed the same.

Global code search uses exact code search as soon as searching is on and a Zoekt node is available for search (ee/app/services/concerns/search/zoekt_searchable.rb:9-13, ee/app/services/ee/search/global_service.rb:21-24,37-38, and for a search with no group or project ee/app/models/search/zoekt.rb:13-15, where !219411 (merged) added the node check). Group and project code search wait until the namespace's index or replica is ready (ee/app/models/search/zoekt.rb:17-21).

The advanced search procedure already selects Search with advanced search only after indexing completes (doc/integration/advanced_search/elasticsearch.md:420-424). These steps give exact code search the same order, which holds whether or not the global check later waits for a ready index: index all root namespaces or chosen groups, wait for replicas and indices to be ready, then select Enable searching. The UI steps and the Rake task section now say that global code search results are incomplete until the initial indexing finishes. The wait step also checks the EnabledNamespace count line of the gitlab:zoekt:info Rake task output for a total above zero with without indices: 0.

In that order on the 19.5 nightly build, code search used advanced search and returned results at every level while the namespaces indexed. Global code search first used exact code search 7 seconds after Enable searching was saved, and on every request from 36 seconds after, returning results throughout. The wait step names replicas because they turned ready about a minute after the indices. Selecting searching first also lets project code search return HTTP 500 for a short time per namespace while its index is ready and its replica is not, on both builds; in the new order no request failed.

The checkbox labels are quoted from ee/app/models/search/zoekt/settings.rb:40,45,55.

A second commit changes the Global cell for Code in the Available scopes table of doc/user/search/exact_code_search.md from no to yes. The cell stayed at no when the zoekt_cross_namespace_search feature flag it depended on was removed in !213413 (merged). Global code search now needs only a license, the searching setting and one searchable Zoekt node (ee/app/services/concerns/search/zoekt_searchable.rb:9-13, ee/app/models/search/zoekt.rb:13-15,37-42). The GitLab.com footnote on that table still says global search is not enabled there.

Related issues

Related to #585561 (closed) (closed), the same symptom: empty global search beside working group search.

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

An AI coding assistant wrote this change. The assistant also checked each step and label against the settings and search code cited above, ran the project's Vale and markdownlint configuration on the changed pages, and ran the old steps on GitLab 19.4.1 and a 19.5 nightly build and the new steps on the nightly build, each on a Linux package instance.