Code Intelligence: Update configuration policy UI

[umpox]

Updates the code intel configuration policy with various changes and improvements.

Closes https://github.com/sourcegraph/sourcegraph/issues/47111

Related designs

What this PR does do

This PR has quite a lot of small changes that don't make sense to split into different PRs but equally are hard to infer from the diff in a single PR. Here is my log of what has changed (aside from just general fixes and improvements):

• Configuration policy list page
  • Added Button dropdown to replace 3 horizontal buttons.
    • Defaults to HEAD
    • This is similar to Batch Changes. I think this component is a good candidate for Wildcard (will move in future PR)
  • Shifted protected icon to the right, to replace the empty space where the delete icon was and make the list more consistent
    • Note: In a future PR I want to move the default policies into their own space. Haven't done it here as it makes sense to update the BE to allow filtering.
  • Converted policy names into links, so it’s more obvious to the user that they are actionable (and stuff like the default ones are viewable).
• Configuration policy page
  • General
    • Updated input width to be smaller, to make it more obvious this is a form, as per designs.
    • Updated headings to use correct labels and link them with input fields for accessibility
    • Move indexing/retention toggles to left side to match other inputs, as per design.
    • Defaulted the policy name instead of a placeholder, so a user isn’t presented with an error when they first load.
    • Various other wording changes and UX polish
    • Fixed bug where the policy did not validate that the global auto indexing setting was not violated. (It let the user save the policy). Also moved the alert directly below the Save button for easier reading.
  • Configure Git objects
    • Moved the matching results table to be directly below input, for easier reading.
    • Added ability to fetch all matching git objects (no longer limited to just 15)
    • Added scrolling behaviour if user fetches more than 15 objects.
    • Moved loading spinner UX to be contained within input.
    • Made wording clearer when combined with auto-indexing logic
    • Object links now open in a new tab, to avoid users accidentally losing config
  • Add repo patterns
    • Updated UI to match design
    • Fixed input and actions size to make it easier to quickly add/remove filters
    • Improved autofocus logic
    • Changed default “This matches all repositories” text to be clearer with an obvious CTA to add repositories filter.
    • Cleaned up loading spinner and error UI screens.
    • Fixed race condition bug between network and user input due to render logic.
    • Added placeholder to help users understand different patterns
  • Repo list
    • Added ability to fetch all matching repositories (no longer limited to just 15)
    • Added scrolling behaviour if user fetches more than 15 repos.
    • Updated “Too many matching repositories” wording to match design and link directly to site admin settings.
    • Updated repository name logic so that the code host is displayed. This matches what would be expected in the filtering logic so it should be a lot easier for the user to understand how to manipulate this list.
    • Repo links now open in a new tab, to avoid users accidentally losing config

What this PR does not do

• Shift components around into different structures. I've avoided this mostly, aside from changes that can are required to fix render bugs. This to keep the diff relatively clean. In a future PR I can move this around
• Significantly change the render logic. There's some improvements we can make to streamline these components a bit. I fixed a few bugs where we are over rendering (and causing UX issues), but avoided minor issues. Time is limited so I'm focusing on areas where we get the biggest UX wins right now.

Some screenshots

Test plan

Tested locally

App preview:

• Web

Check out the client app preview documentation to learn more.

[sg-e2e-regression-test-bob]

Bundle size report 📦

Initial size	Total size	Async size	Modules
0.00% (0.00 kb)	0.03% (+4.67 kb)	0.04% (+4.67 kb)	0.00% (0)

Look at the Statoscope report for a full comparison between the commits dc1da00 and e2ede87 or learn more.

Open explanation

• Initial size is the size of the initial bundle (the one that is loaded when you open the page)
• Total size is the size of the initial bundle + all the async loaded chunks
• Async size is the size of all the async loaded chunks
• Modules is the number of modules in the initial bundle

[umpox]

@efritz @rrhyne If you get chance, please take a look and LMK your thoughts on the UX. Keen to iterate on this as required

[efritz]

👍

plan to address this issue before EoW

[efritz]

Just to chat about future directions:

Note: In a future PR I want to move the default policies into their own space. Haven't done it here as it makes sense to update the BE to allow filtering.

Note that the "protected" policies are hard-coded into the instance, so there will only ever be a handful (right now three, and there's no pressure to add another default). Is that your looking for here just a "protected/non-protected" filter on the GraphQL endpoint to fetch all related policies?

Added ability to fetch all matching repositories (no longer limited to just 15)

If we ask for all bracnhes on a large monorepo (matching '*' for instance) do we expect to have some text like "See all 12384791874 tags" and expect to render them all? Do we want to add some kind of upper bound here on either the frontend (if over some threshold render a non-actionable link) or backend (maximum allowable return set size)?

[umpox]

@efritz

Note that the "protected" policies are hard-coded into the instance, so there will only ever be a handful (right now three, and there's no pressure to add another default). Is that your looking for here just a "protected/non-protected" filter on the GraphQL endpoint to fetch all related policies?

That's right. There isn't a nice way to filter these out on the client as it requires fetching the entire list (we also currently paginate and allow filtering, so gets weird). It'd be ideal if we had a simple GQL variable to filter against protected/non-protected policies.

If we ask for all bracnhes on a large monorepo (matching '*' for instance) do we expect to have some text like "See all 12384791874 tags" and expect to render them all? Do we want to add some kind of upper bound here on either the frontend (if over some threshold render a non-actionable link) or backend (maximum allowable return set size)?

Good point. I have set 1000 as a limit for both repositories and git branches/tags. That feels reasonable enough to me as something which should cover most use cases without leading to users accidentally triggering a huge query. LMK if you disagree

[sourcegraph-bot]

Codenotify: Notifying subscribers in CODENOTIFY files for diff e2ede87...dc1da00.

Notify

File(s)

@efritz

client/web/src/enterprise/codeintel/configuration/components/RepositoryPatternList.module.scss client/web/src/enterprise/codeintel/configuration/components/RepositoryPatternList.tsx client/web/src/enterprise/codeintel/configuration/hooks/usePreviewGitObjectFilter.tsx client/web/src/enterprise/codeintel/configuration/hooks/usePreviewRepositoryFilter.tsx client/web/src/enterprise/codeintel/configuration/pages/CodeIntelConfigurationPage.module.scss client/web/src/enterprise/codeintel/configuration/pages/CodeIntelConfigurationPage.tsx client/web/src/enterprise/codeintel/configuration/pages/CodeIntelConfigurationPolicyPage.module.scss client/web/src/enterprise/codeintel/configuration/pages/CodeIntelConfigurationPolicyPage.tsx client/web/src/enterprise/codeintel/configuration/shared.ts