Add zoekt feature flags to application settings

Proposal

  • Within the Admin Area, rename "Settings > Advanced search" to "Settings > Search"
  • Add a new section to the "Settings > Search" page for Zoekt configuration

Business case

At the moment, this primarily benefits GitLab.com admins while we support the rollout of Zoekt. As part of the rollout, a namespace can land in one of several states:

  • Not indexed
  • Actively indexing
  • Indexed and Zoekt enabled for the namespace

Currently users can opt of out of Zoekt code search for themselves, but admins cannot control it at the instance / namespace level. This is putting support burden on our team as they have to toggle Zoekt for customers that have reached out. By adding these controls to the Admin Area, we are able to address customer requests more rapidly.

Going forward, we are rolling out Zoekt code search to SM customers, with a few currently using the alpha version of our Helm chart. As more SM users adopt this capability over ElasticSearch, they will need a way to view and manage the Zoekt indices. This page will support that need.

Validation path

Since this is impacting a limited audience (i.e. only GitLab Admins), we can follow the limited validation path for this change.

Other locations that were considered

  • Standalone "Settings > Code search settings" entry in the Admin area: While this matches the way the features are built (advanced search and code search are completely independent features), we decided that this flow did not match how end users think about setting up and managing search in their GitLab instance.

Checklist

  • Review the handbook page for navigation.
  • Add relevant information to the issue description detailing your proposal, including usage and business drivers.
  • List at least two other places you considered to introduce your feature.
  • Add relevant designs to the Design Management area of the issue.
  • Ensure your UI suggestion align with the Documentation Style Guide.
  • Engage Technical Writing. They can help craft a term that best describes the feature(s) you’re proposing.
  • Follow the product development workflow validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is mandatory for additions or when restructuring.
  • Engage the Foundations Product Manager for approval. The Foundations DRI ( @jtucker_gl) will work with UX partners in product design, research, and technical writing, as applicable.
  • Consider whether you need to communicate the change somehow, or if you will have an interim period in the UI where your item will live in more than one place.
  • Ensure engineers are familiar with the implementation steps for navigation.
Edited by Jeff Tucker