Not displaying repo headers for now, this was quicker to implement and it might be a good enough design. We can refine later, but for now, it gives value that we can see this type of hits.
* JetBrains: Move title into web view and add loading indicator
* Move progress status underneath search box and bring back popover title
* Fix height jumping
* Update icons to higher fidelity version
This is a pattern we started using a while ago, but the code in searcher
predates that. This was done via gopls doing renames.
Test Plan: go test
Accidently squashed merged into this commit, for convenience just combinging:
* searcher: prometheus gauge for SEARCHER_CACHE_SIZE_MB (#36162)
This is to allow us to create a dashboard which includes the configured
maximum size of the cache or make a percentage of cache used. This will
make it easier to check admin configurations, since we don't need to
check the configuration we can just check the dashboard.
Test Plan: started locally and checked the value of
searcher_store_max_cache_size_bytes in the metrics page for searcher.
I don't see many uses of log.WithTrace, but I think this is because it
is clunky to use since Span or Context may be nil on a context. This
introduces a helper so we can start logging against a span more easily.
Here is an example of using it I want:
logger := trace.Logger(ctx, s.Log).Scoped("...", "...").With(...
This seems like the best place to add the logger, since we need to use
internal functions in the trace pkg (ie won't work in lib/log).
I updated the documentation to include an example of it. Right now the
documentation has one other place it calls WithTrace, but it needs to be
reworked to be more realistic. I think calling log.Scoped on something
that is traced seems surprising to me.
Test Plan: unused, so just that CI is happy.
Co-authored-by: Robert Lin <robert@bobheadxi.dev>
This adds a bunch of comments to HunkMatch since I think I'm happy with
where this design landed. Additionally, it adds MatchedContent, which
returns the exact set of strings matched by the query. It's not used
except in tests yet, but I wanted to add that now to pin that behavior
since that's critical to the design of what we store in HunkMatch.
This refines the new HunkMatch type to include PreviewStart so that
we have both the line number and the byte offset of Preview available
for further processing. PreviewEnd can always be calculated from
Preview, so I felt it was best to just provide a start location rather
than a range that is represented by Preview.
This replaces MultilineMatch with a slightly more general HunkMatch.
One of the design limitations of MultilineMatch is that it requires duplicating the content of the full line for every matched range. One of the things that is nice about LineMatch is that it can match the same line many times, but only send the content once. When we implemented MultilineMatch, this was known, but I naively thought it would be fine since we don't send that many results with a bunch of matches per line.
I was wrong. The thing is, for very large lines, there are often also very many matches. This means as the line gets longer and there are more likely matches, we also send the larger line more times. This bad
behavior causes us to hit our max payload size limit for very long lines because they are sent very many times.
So, instead, we get HunkMatch. A HunkMatch is like a MultilineMatch, except it can contain any number of matched ranges (which are allowed to cross line boundaries) within that hunk.
* fix search result match range highlighting after a unicode character
Change `highlightNode.ts` to highlight ranges based on code point index instead of byte index.
In `highlightNode.ts`, string indexing is used to highlight match ranges in search results. However, the range indexes coming from the search backend are counted in terms of runes, whereas string indexing is based on bytes.
JavaScript uses UTF-16 string encoding, which encodes Unicode code points as either one or two hex characters. This was causing highlight ranges to be offset by one when the range came after a two-hex-character-encoded Unicode code point, such as certain emojis. Unpacking a string into an array of code points before slicing the range to be highlighted fixes this issue.
* run prettier
* Add collapse visual state to the drill-down panel for the independent insight page
* Fix forward ref problem around drill down search context filter
* Add mobile layout for the drill-down filters panel
* Fix bad layout for the collapse filters section
* Show search based suggestions only on input focus event
* Support context prefix for the search context pill preview
For example this can happen when searcher renames a file. We shouldn't
bail out early, but rather lets work on best effort information.
Test Plan: this is tough to reproduce, so instead I am relying on tests
to catch any possible regressions.
* Clear up the terminology for search results:
- Made a very clear distinction between “match” (what Sourcegraph returned) and “result” (a selectable item that we display)
- Renamed “idForLine” to “resultId”
- Renamed “idForMatch” to “matchId”
- Made naming specific to content search where the logic is specific to content search (in preparation for handling other search types)
- Changed the interface of `getSiblingResult()`
* Add “commit” search result display
* Fix Windows-style line breaks
* Add “repo” search result display
* Move the view grid to the insight directory
* Move all core components to the chart directory
* Implement code insight example card with new InsightCard UI API
With gitlab now enforcing token expiry in 2 hours, this is an easier
way for the customer to renew their oauth token. Without this functionality
the customer needs to remove the code host connection and re-add it.
However removal of code host connection also removes any repos attached
to it. Which would lead to customer needing to re-add all of the repos again
as well.
Instead this PR shows an Update button when the token is expired, allowing
the customer to go over the oauth flow to get a new token without
forcing them to remove the code host connection (and repos).
Related: https://github.com/sourcegraph/customer/issues/968
ObservationContext on diskcache was introduced in 5ac235a5f. This means
for about 5 months we haven't had metrics for it on searcher. This
commit is the most minimal introduction for it. We don't yet integrate
ObservationContext into searcher.
I considered just constructing an ObservationContext in Start, but then
the prometheus registry would panic in tests due to multiple
constructions of it.
Test Plan: go test and running an unindexed search locally.
