search: rename repo:contains predicates to be consistent#40389
Conversation
…ontent:b); rename repo:contains.file(a) to repo:contains.path(a)
| 'Search only inside repositories that contain a file matching the `file:` with `content:` filters.', | ||
| examples: ['repo:contains(file:CHANGELOG content:fix)'], | ||
| 'Search only inside repositories that contain a file path matching the `path:` and/or `content:` filters.', | ||
| examples: ['repo:contains.file(path:README content:fix)'], |
There was a problem hiding this comment.
repo:contains.file(path:CHANGELOG content:fix) was too long to fit fully into the sidebar. I don't know how line wrapping is handled in the sidebar but it was easiest to just shorten the example string.
c0d0b20 to
8ed6157
Compare
…epo:contains.file` and `repo:contains.path`
8ed6157 to
71c452b
Compare
6f345ff to
de85328
Compare
| // repo:contains() is not supported, use repo:contains.file() or repo:contains.path() | ||
| if (path.length === 1 && path[0] === 'contains') { | ||
| return undefined | ||
| } |
There was a problem hiding this comment.
This is to disable syntax highlighting for repo:contains() to make it visually clear it's not valid anymore. This feels like a band-aid but seemed like the least disruptive way to achieve that end.
There was a problem hiding this comment.
Ended up reverting this change because it affected file:contains.content. I still want to disable syntax highlighting for repo:contains() but will handle that in a follow-up to limit the scope of this PR.
|
Codenotify: Notifying subscribers in CODENOTIFY files for diff e0289af...d44ee77.
|
rvantonder
left a comment
There was a problem hiding this comment.
stamping to unblock since this is a mechanical change :-)
pls add changelog entry if I missed it
|
Integration tests failing, will look tomorrow, it's late here |
|
Am I correct in assuming this is not backwards compatible? If so, that's going to be a problem for products with persisted queries such as Code Insights, without either some effort to migrate those queries or time to notify customers. Maybe I'm missing something here though, please let me know. cc @Joelkw |
|
@coury-clark IIRC code insights enforces a single repo (or maybe custom set of repos) and doesn't support repo regex/predicates? If it does support anything beyond single or discrete multi-repo set then we should call this out as a breaking change in 4.0 (in practical terms I suspect there is a <1% chance that queries using that specific syntax persist (see original issue for syntax changes), and the burden of maintaining backwards compatibility is not worth the effort on our side. I.e., we are best off declaraing a breaking change in a major version version release that is unlikely to practically impact users, than ensuring backwars compatibility) |
|
@rvantonder You're right, there are some light validations after certain versions to exclude executing Having said that, other products / usage exist (Notebooks, monitors, batch changes, etc) as well as just general usage such as links. I think that in general a breaking change in our syntax deserves at least some lead time and notice, even if usage is low. Apologies if I missed something, but I didn't see any kind of notice for this change either internally or customer facing. |
|
@coury-clark No we didn't send a department-wide notice regarding our plans to make this change. It should have occurred to me to do that more proactively, so my bad there. That said, I haven't actually formally requested review from anyone on this PR yet, so I will go ahead and tag backend-devs on this now for visibility. I'm fine with holding off on merging this PR if others raise concerns. But, I also lean toward the side of thinking the impact of this will not be that large. |
1eecbd9 to
d44ee77
Compare
|
Will go ahead with merging this later today if there are no objections cc @sourcegraph/search-product |
@tbliu98 can you post this in #search, then cross share to #eng-announce, and ask anyone to raise concerns in the thread? This will give visibility to CEs, etc. |
Part of #39767
As described in the linked issue, this PR:
repo:contains(file:a content:b)torepo:contains.file(path:a content:b)repo:contains.file(a)torepo:contains.path(a)repo:contains(file:a content:b)Note that if we think keeping
repo:containsaround is actually the way to go, it will be easy to add it back.This PR includes corresponding frontend changes to syntax highlighting, hovers, and the search reference panel.
Test plan
Updated unit tests. Integration tests. Manually tested hovers/suggestions/syntax highlighting/reference panel