This commit is in preparation for other work. It refactors how we work
with resolved repository and resolved revision information.
The idea was that the top level repo loader should try to resolve the
repository information and error if that wasn't possible. Not being able
to resolve the revision was accepted, hence this check:
```js
// still render the main repo navigation and header
if (!isRevisionNotFoundErrorLike(repoError)) {
error(400, asError(repoError))
}
```
However the way it was implemented meant that we wouldn't pass any
resolved repository information to the sub-pages/layouts when the
revision couldn't be resolved, which seems wrong.
With these changes, the top level repo loader now provides a
`resolvedRepository` object (where `commit`/`changelist` might be unset)
and the `(validrev)` loader creates the `resolvedRevision` object, just
how its sub-pages/layouts expect.
And instead of returning error objects from `resolveRepoRevision` and
checking them in the loader we throw errors/redirects directly in that
function. IMO that makes the whole flow easier to understand.
## Test plan
Manual testing, CI integration tests
In preparation for other work, this commit substantially refactors the
"infinity query" store implementation. The internals have been changed
completely which allows us to simplify its public API.
- Simpler configuration, especially merging previous and next results.
- Restoration support. So far pages/components had to implement
restoring the state of an infinity store on their own. Now the
restoration strategy is part of the configuration. Pages/components only
have to get an opaque snapshot via `store.capture()` and restore it via
`store.restore(snapshot)`.
- More predictable state. It wasn't always obvious if the store content
stale data e.g. during restoring data. Now `data` will only be set when
the data is 'fresh'.
- Smarter 'incremental restoration' strategy. This strategy makes
multiple requests to restore the previous state. It makes multiple
requests because normally requests are cached and there this is fast.
When the data is not cached though there is a noticable delay due to
waterfall requests. Now we use a simple heuristic to determine whether
or not GraqhQL data might be cached. If not we make a single request to
restore the state.
For review I suggest to turn whitespace changes off.
## Test plan
Manual testing, unit tests.
- Remove long-deprecated and long-ineffective notifications for saved
searches (removed in
de8ae5ee28
2.5 years ago). Note that code monitors were the replacement for saved
searches and work great.
- Clean up UI.
- Make the UI global instead of in the user/org area.
- Convert React class components to function components.
- Add default `patterntype:` because it's required.
- Use `useQuery` and `useMutation` instead of `requestGraphQL`.
- Use a single namespace `owner` GraphQL arg instead of separating out
`userID` and `orgID`.
- Clean up GraphQL resolver code and factor out common auth checking.
- Support transferring ownership of saved searches among owners (the
user's own user account and the orgs they're a member of).
(I know this is not in Svelte.)
SECURITY: There is one substantive change. Site admins may now view any
user's and any org's saved searches. This is so that they can audit and
delete them if needed.
## Test plan
Try creating, updating, and deleting saved searches, and transferring
ownership of them.
## Changelog
- Improved the saved searches feature, which lets you save search
queries to easily reuse them later and share them with other people in
an organization.
- Added the ability to transfer ownership of a saved search to a user's
organizations or from an organization to a user's account.
- Removed a long-deprecated and ineffective settings
`search.savedQueries` field. You can manage saved searches in a user's
or organization's profile area (e.g., at `/user/searches`).
This is a refactor with a few incidental user-facing changes (eg not
showing a sometimes-incorrect total count in the UI).
---
Make `usePageSwitcherPagination` and `useShowMorePaginationUrl` support
storing filter and query params, not just pagination params, in the URL.
This is commonly desired behavior, and there are many ways we do it
across the codebase. This attempts to standardize how it's done. It does
not update all places this is done to standardize them yet.
Previously, you could use the `options: { useURL: true}` arg to
`usePageSwitcherPagination` and `useShowMorePaginationUrl`. This was not
good because it only updated the pagination URL querystring params and
not the filter params. Some places had a manual way to update the filter
params, but it was incorrect (reloading the page would not get you back
to the same view state) and had a lot of duplicated code. There was
actually no way to have everything (filters and pagination params)
updated in the URL all together, except using the deprecated
`<FilteredConnection>`.
Now, callers that want the URL to be updated with the connection state
(including pagination *and* filters) do:
```typescript
const connectionState = useUrlSearchParamsForConnectionState(filters)
const { ... } = usePageSwitcherPagination({ query: ..., state: connectionState}) // or useShowMorePaginationUrl
```
Callers that do not want the connection state to be reflected in the URL
can just not pass any `state:` value.
This PR also has some other refactors:
- remove `<ConnectionSummary first>` that was used in an erroneous
calculation. It was only used as a hack to determine the `totalCount` of
the connection. This is usually returned in the connection result itself
and that is the only value that should be used.
- remove `?visible=N` param from some connection pages, just use
`?first=N`. This was intended to make it so that if you reloaded or
navigated directly to a page that had a list, subsequently fetching the
next page would only get `pageSize` additional records (eg 20), not
`first` (which is however many records were already showing) for
batch-based navigation. This is not worth the additional complexity that
`?visible=` introduces, and is not clearly desirable even.
- 2 other misc. ones that do not affect user-facing behavior (see commit
messages)
## Test plan
Visit the site admin repositories and packages pages. Ensure all filter
options work and pagination works.
This PR adds better gating for disabling the code monitors, notebooks, search jobs and own features.
Test plan:
Ran locally and verified the features are gone when the env var is set. Ran again without those and they worked.
## Linked Issues
- Closes https://github.com/sourcegraph/sourcegraph/issues/35027
## Motivation and Context:
<!--- Why is this change required? What problem does it solve? -->
- To improve the UX by displaying the invalid token error message on the
UI to the users while adding a code host connection
## Existing Issue Root Cause:
- After the submit button is clicked while adding a code host
connection, the existing code navigates to the
`/site-admin/external-services/${data.addExternalService.id}` page (the
page which displays information of the newly added code host connection)
before the error message could even be displayed on the current page
## Changes Made:
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. List any
dependencies that are required for this change. -->
- Modified the onSubmit function (the one which is called when the
submit button is clicked on the code host connection addition page) to
only navigate to the
`/site-admin/external-services/${data.addExternalService.id}` page
(newly added code host information page) only if no error/warning is
returned from the gRPC call which validates the token of the code host
added
## Type of change:
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Refactoring (altering code without changing its external
behaviour)
- [ ] Documentation change
- [ ] Other
## Checklist:
- [x] Development completed
- [x] Comments added to code (wherever necessary)
- [x] Documentation updated (if applicable)
- [x] Tested changes locally
## Follow-up tasks (if any):
- None
## Test Plan
<!--- Please describe the tests that you ran to verify your changes.
Provide instructions so we can reproduce. -->
- Had setup the codebase locally and tested the entire flow locally
end-to-end
- Screen recording which shows the invalid token error message on the UI
in the code host connection addition flow:
https://github.com/sourcegraph/sourcegraph/assets/51479159/1857f32d-56a6-42c1-af88-ea3c9edc46a5
## Additional Comments
- Please let me know if any further changes are required elsewhere
In Sveltekit, we respect the setting `search.defaultPatternType` for the
initial search, but if you set then unset the regexp toggle, it always
reverts to `keyword`. Now we revert back to the default when a toggle is
unset.
This is important because some customers have disabled keyword search,
and for 5.5 we've directed them to use `search.defaultPatternType:
standard`.
## Test plan
Manually tested search + toggles with following config:
* No settings
* `search.defaultPatternType: standard`, `keyword`, and `regexp`
This adds two new components for the common situation of needing to
display a styled path.
- `DisplayPath` handles splitting, coloring, spacing, slotting in a file
icon, adding a copy button, and ensuring that no spaces get introduced
when copying the path manually
- `ShrinkablePath` is built on top of `DisplayPath` and adds the ability
to collapse path elements into a dropdown menu
These are used in three places:
- The file header. There should be no change in behavior except maybe a
simplified DOM. This makes use of the "Shrinkable" version of the
component.
- The file search result header. This required carefully ensuring that
the text content of the node is exactly equal to the path so that the
character offsets are correct.
- The file popover, where it is used for both the repo name (unlinkified
version) and the file name (linkified version).
Fixes SRCH-718
Fixes SRCH-690
We register ctrl+backspace to go to the repository root, but that should
not trigger when an input field, such as the fuzzy finder, is focused.
Fixes srch-681
## Test plan
Manual testing.
## Linked Issues
- Closes https://github.com/sourcegraph/sourcegraph/issues/38348
## Motivation and Context:
<!--- Why is this change required? What problem does it solve? -->
- Improves the UX of the password reset flow
## Changes Made:
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. List any
dependencies that are required for this change. -->
- Made changes to the following 2 flows:
- On the new password entry screen:
- Added a text which displays the email of the account for which the
password change request has been raised
- Added a back button to allow the users to go back to the previous
email entry screen if the account they want to reset the password for is
different
- On the sign-in screen which comes after successful password reset
request completion:
- Made changes to auto-populate the email text-box with the email linked
to the account on which the password reset request was completed
recently
## Type of change:
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [ ] Refactoring (altering code without changing its external
behaviour)
- [ ] Documentation change
- [ ] Other
## Checklist:
- [x] Development completed
- [ ] Comments added to code (wherever necessary)
- [ ] Documentation updated (if applicable)
- [x] Tested changes locally
## Follow-up tasks (if any):
- None
## Test Plan
<!--- Please describe the tests that you ran to verify your changes.
Provide instructions so we can reproduce. -->
- Setup the codebase locally along with configuring a custom SMTP to
enable the email delivery functionality with the help of this
documentation:
https://docs.sourcegraph.com/admin/config/email#configuring-sourcegraph-to-send-email-using-another-provider
- Tested the entire flow locally end-to-end.
- Screen recording of the password reset screen where the current email
ID is added along with a back button:
https://github.com/sourcegraph/sourcegraph/assets/51479159/a79fc338-ace0-4281-86d2-de7cc68eae20
- Screen recording of the sign-in screen after password reset is
successfully done where the email ID is auto-populated in the text-box:
https://github.com/sourcegraph/sourcegraph/assets/51479159/be7db65d-9421-4621-a1e9-a04a546b9757
## Additional Comments
- Please let me know if I need to make any further design changes from
the frontend side or any API contract related changes from the backend
side
---------
Co-authored-by: Vincent <evict@users.noreply.github.com>
Co-authored-by: Shivasurya <s.shivasurya@gmail.com>
This PR overhauls the UI a bunch to make it look more in line with other
pages, and fixes various smaller papercuts and bugs.
Closes SRC-377
Test plan:
Added storybooks and made sure existing ones still look good, created,
updated, deleted various webhooks locally.
I went through all call sites of the 3 search APIs (Stream API, GQL API,
SearchClient (internal)) and made sure that the query syntax version is
set to "V3".
Why?
Without this change, a new default search syntax version might have
caused a change in behavior for some of the call sites.
## Test plan
- No functional change, so relying mostly on CI
- The codeintel GQL queries set the patternType explicitly, so this
change is a NOP.
I tested manually
- search based code intel sends GQL requests with version "V3"
- repo badge still works
- compute GQL returns results
A couple of tweaks to the commit / diff view:
- Linking both file paths in the header for renamed files
- Collapse renamed file diffs without changes by default
- Move "no changes" out of `FileDiffHunks` to not render a border around
the test.
- Add description for binary files
- Adjust line height and font size to match what we use in the file view
- Added the `visibly-hidden` utility class to render content for a11y
purposes (I didn't test the changes I made with a screenreader though)
Contributes to SRCH-523
## Test plan
Manual testing
This commit removes files/dependencies that we are not using (anymore).
In the case of `@sourcegraph/wildcard` we never want to import
dependencies from it, but have done so accidentally in the past. I hope
that we can prevent this by removing it from dependencies (and we don't
need anyway).
## Test plan
`pnpm build` and CI
Removes the `sg telemetry` command that pertains to the legacy V1
exporter that is specific to Cloud instances.
I got asked about this recently, and especially with the new `sg
analytics` for usage of the `sg` CLI, this has the potential to be
pretty confusing.
Part of https://linear.app/sourcegraph/issue/CORE-104
## Test plan
n/a
## Changelog
- `sg`: the deprecated `sg telemetry` command for allowlisting export of
V1 telemetry from Cloud instances has been removed. Use telemetry V2
instead.
Closes srch-494
This adds the search query syntax introduction component to the search
homepage. I tried to replicate the React version as closely as possible.
I originally wanted to reuse the logic to generate the example sections
but since it had dependencies on wildcard I duplicated it instead.
Notable additional changes:
- Added a `value` method to the temporary settings store to make it
easier to get the current value of the settings store. It only resolves
(or rejects) once the data is loaded.
- Extended the tabs component to not show the tab header if there is
only a single panel. This makes it easier for consumers to render tabs
conditionally.
- Added the `ProductStatusBadge` component
- Various style adjustments
For reference, the relevant parts of the React version are in
https://sourcegraph.sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/client/branded/src/search-ui/components/useQueryExamples.tsx
and
https://sourcegraph.sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/client/branded/src/search-ui/components/QueryExamples.tsx
## Test plan
Manual testing. I manually set the value received from temporary
settings to `null` (in code) to force trigger the compute logic.
Fixes srch-589
This implements the 'y' shortcut to navigate to the permalink page, just
like we have in the React app.
According to aria guidelines it should be possible to disable single
character shortcuts but this actually never worked for the 'y' shortcut
because it was implemented differently. So adding it without the option
to turn it off is at least not a regression.
For reference this the code handling the shortcut in the React app:
https://sourcegraph.sourcegraph.com/github.com/sourcegraph/sourcegraph@d9dff1191a3bad812aa5b50315b8e77ee0e40e55/-/blob/client/web/src/repo/actions/CopyPermalinkAction.tsx?L64-77
When initially implementing this I noticed that there is a slight delay
between pressing 'y' and the URL/UI updating. That's because SvelteKit
has to wait for `ResolveRepoRevision` call to resolve before updating
the page. A new request is made because the URL changes which triggers
the data loader. But we already know that such a request will return the
same data, so the request is unnecessary. To avoid the second call I
added another caching layer.
I also noticed that the last commit info would be reloaded which is
unnecessary. I changed the implementation to use the resolved revision
instead of the revision from the URL. Now the request will be properly
cached on the commit ID and the implementation is also much simpler.
## Test plan
Manual testing.
Closes srch-103
Currently we don't show the global context filter on the search home
page or the search results page (global context is the default context).
This commit does two things:
- It prefills the search input on the search homepage with the user's
default context (like the React app)
- It the logic that pre-processed the search query and removed the
context filter if it was global.
In other words we simplify the query logic by showing/submitting the
search query as is. Notably this doesn't affect how the search input
works on repo pages.
## Test plan
- Opening the search home page pre-fills the query input with the
default search context
- Submitting a query without a `context:` filter does not add a
`context:` filter to the URL or the search input
- If a query contains `context:global` that filter is preserved in the
query input (it wasn't before)
We don't like the style/alignment of the Lucide case sensitivity and
regex icons (the structural search icon seems fine). This commit
switches them back to the MDI icons that we used before.
Solution or temporary workaround (tbd) for srch-544
## Test plan
Manual testing.
Closes srch-612
This commit adds a link next to the blame commit message that allows
reblaming to a prior commit if available.
It extends the existing blame extension. This won't have any affect on
the React app because it doesn't pass the configuration option needed to
add the extra gutter.
Some notes:
- I originally used the tooltip component instead of `title` but somehow
it starts to break when scrolling the document (tooltips don't show up
anymore). I don't know if CodeMirror does anything to the DOM elements
that causes this to fail.
- The reblame URL also selected the corresponding line so that the
correct line is scrolled into view.
## Test plan
Manual testing
https://linear.app/sourcegraph/issue/SPLF-116/perforce-searching-by-perforce-changelist-id
## Details
We have had requests from our customers using Perforce to be able to
search inside of a changelist id. For a commit sha we support doing this
```
context:global repo:^perforce-sgdev-org/rhia-depot-test$@345c17c` some text
```
But for perforce they want to do the same thing but with the change list
ids. Which would look like this
```
context:global repo:^perforce-sgdev-org/rhia-depot-test$@changelist/83732` some text
```
To support this, I am attempting to smartly detect when we should do a
DB round trip and look up the proper mapping. I built a simple heuristic
that is
1. Is perforce changelist mapping feature flag enabled
2. Is this a perforce repo?
3. Is the revision request a integer ?
This mapping is just a best effort, if it fails it just falls back on
current behavior.
We are doing with a syntax of `@changelist/CL_ID` instead of supporting
`@CL_ID` to future proof us. This lookup focuses on finding the mapping
in the DB but in the future we may want to pre-create these refs in the
db duing mapping of perforce CLs to git commits.
## Limitations
This works well in testing however, the repo name@changelist/rev we
return contains the sha
I investigated changing this but it would required a larger change in
resolving the stream results. While that would be nice to have, I
decided to keep this minimal for now and add that later if needed
## Test plan
<!-- REQUIRED; info at
https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles
-->
## Changelog
- For perforce depots, support searching within a specific changelist by
specifying a ref like `context:global repo:^repo/name$@changelist/83854`
Closes https://linear.app/sourcegraph/issue/CORE-213
The existing overwrite stripping `window.context.authProviders` sourced
from a proxied API down to only built-in providers makes it impossible
to reliably run `sg start web-standalone` against Sourcegraph.com (and
likely other Sourcegraph instances). The docstring says:
> Only username/password auth-provider provider is supported with the
standalone server.
However, you _can_ log in with other OAuth2 providers locally, so it
doesn't make sense to remove them from the context. This PR removes the
overwrite so that we can log in to Sourcegraph.com with a locally
running web app, and talk to Cody and all that good stuff.
## How to log in to OAuth providers with `sg start web-standalone`
IIRC what happens:
1. Click "Sign in" -> go to OAuth2 provider -> log in
2. OAuth2 provider issues callback to the Sourcegraph instance, telling
it that you logged in
3. OAuth2 provider redirects you to the instance to confirm your session
- for SAMS in dotcom:
```
https://sourcegraph.com/.auth/callback?code=sams_ac_...
```
This redirect will surface an error, like so:
> Authentication failed. Try signing in again (and clearing cookies for
the current site). The error was: state parameter did not match the
expected value (possible request forgery).
This happens because you get redirected to an absolute URL, which will
be `sourcegraph.com` (the upstream Sourcegraph instance), which won't
match the cookie you get issued (`sourcegraph.test`). We just need to
make sure it matches and send the code to the callback through our local
proxy:
```diff
- https://sourcegraph.com/.auth/callback?code=sams_ac_...
+ https://sourcegraph.test:3443/.auth/callback?code=sams_ac_...
```
And everything will work :) I confirmed this works for e.g. logging into
S2 with GitHub as well, using the callback issued by GitHub.
We cannot make this the default behaviour, because the redirect URL is
usually configured in the OAuth provider. An example GitHub OAuth
application configuration:
Note their guidance on valid values:
https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#redirect-urls
- we must provide a single, absolute URL
This is very similar to the process used to log in to private Cloud
instances, e.g.
https://cloud-ops.sgdev.org/dashboard/environments/prod/instances/src-bd02273f6b90d1d1beee#log-in-to-the-instance-ui
(scroll to bottom of this section), which indicates we've thought about
similar cases before and found that this was the best way
## Test plan
https://www.loom.com/share/6cb3b3ca475b4b9392aa4b11938e76e6?sid=d99fcb59-4308-45c7-9f68-af9ac44c4e7e
Updating the `cody-web-experimental` package to the latest version which
- Fixed problems with telemetry (now we send agent level of telemetry
events with `Web.Cody` client name)
- Fixed remote repository context as you switch between chats
- Added support for cody context filters in file and symbols mentions
- Improved link rendering for remote files (no more "remote-file://"
protocol prefixes.
Also, this PR adds some missing CSS token overrides for the LLM picker
on dotcom.
Note: I, by accident, pushed the `0.2.2` version with the same build as
I have published already in `0.2.1`. NPM doesn't allow to override the
build with the same version, so I had to publish 0.2.3 to make it
through to the Sourcegraph repo. This is why we jump from 0.2.1 to 0.2.3
## Test plan
-General manual checks for Cody Web
Closes SRCH-706
Previously the success notice would appear in the commit signing area of
the site admin, even if we create a github app for regular code host
stuff. This PR fixes it.
It also udpates the partial storage key of the notice, so that it will
reappear if we create more apps.
## Test plan
Manual testing
## Changelog
<!-- OPTIONAL; info at
https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c
-->
We now have the `gitHubApp` field that can be used instead.
`isGitHubApp` was only introduced as part of the batch changes
integration with github app, and is therefore not released yet.
Closes SRCH-704
## Test plan
Manual testing
## Changelog
<!-- OPTIONAL; info at
https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c
-->
---------
Co-authored-by: Bolaji Olajide <25608335+BolajiOlajide@users.noreply.github.com>
Based on #63677
Closes srch-691
Closes srch-695
This adds the cody button to the repo "home page" so that cody can be
opened from there.
This commit also makes it so that the cody button is hidden when the
sidebar opens (like in the React app) and it adds a fixed height to the
various headers so that they align well with the sidebar header and
don't change size when the cody button is hidden when the sidebar is
open.
## Test plan
Manual testing.
This commit updates cody web, making similar changes as
[ed493c9](ed493c9dd1)
and a81d5e7. I wasn't quite sure about some styles, but I left comments
on the respective PRs and tried to at match the styling.
Most importantly this also fixes cody web in the Svelte app which
currently appears to be broken. I'd like to get this in as quickly as
possible (hence stampers), styles can always be tweaked later.
Additional changes:
- Fixed layout (chat container was overflowing).
- Set font family and size to the same we use in the Svelte app for
consistency.
## Test plan
Manual testing.
This is part of the Keyword GA Project.
Batch Changes uses Sourcegraph queries to define the list of repositories on which the batch change will run.
With this change we default to pattern type "keyword" instead of "standard".
To make this a backward compatible change, we also introduce a version identifier to batch specs. Authors can specify `version: 2` in the spec, in which case we default to pattern type "keyword". Existing specs (without a specified version) and specs with `version: 1` will keep using pattern type "standard".
Notes:
- Corresponding doc update [PR](https://github.com/sourcegraph/docs/pull/477)
- We don't have a query input field, but instead the query is defined in a batch spec YAML. It didn't feel right to edit the YAML and append "patternType: " on save, which is what we do for Code Monitors and Insights.
- I misuse the pattern type query parameter to effectively override the version. Once we introduce "V4" we should come back here and clean up. I left a TODO in the code.
Test plan:
- New and updated unit tests
- manual testing
- new batch changes use `version: 2` by default.
- using an unsupported version returns an error
- I ran various "on:" queries to verify that version 2 uses keyword search and version 1 uses standard search.
This commit adds support for cody ignore settings to the SvelteKit app.
When cody is disabled on the instance or for the user, the cody button
and sidebar are not shown anymore.
Likewise if the repository is excluded from cody, the buttons and
sidebar are not shown.
The implementation was inspired by `useCodyIngore.ts`, but simplified
for use in the SvelteKit app. It seems that the file exclusion logic is
not actually used for the sidebar and thus was omitted. It also seems
that for the sidebar itself we are only checking whether the current
repository is excluded or not, which lets us simplify the whole setup
and simply pass a boolean (store) from the data loader, indicating
whether cody is enabled or not.
Furthermore I introduced zod to validate that the value of
`codyContextFilters.raw`, which is typed as `JSONValue`, has the
expected shape. We've run into issues in the past where such values have
just been cast to the expected Typescript type. zod adds runtime
validation.
Note that we use JSON schema base validation (with `ajv`) in some
places, but that requires importing and sending the whole JSON schema to
the client, which is something I'd like to avoid. The advantage JSON
schema is that we also use it for generating Go code. We should find a
way to use JSON schema but generate specific validators at build time.
There are also other libraries that do runtime validation and are
smaller but they don't necessarily allow asynchronous validation (which
we want to do because we only want to import the `re2js` library when
necessary; of course we could organize the code differently but it's
nice to be able to encapsulate this logic)
## Test plan
Manual testing and new integration tests.
These commits do a few things:
---
46b1303e62ea7e01ba6a441cc55bbe4c166ef5ce corrects a few minor mistakes
with the new site config which I introduced in #63654 - namely fixing
`examples` entries and nullability in a few cases. Nothing controversial
here, just bug fixes.
---
750b61e7dfa661338c9b40042087aed8e795f900 makes it so that the
`/.api/client-config` endpoint returns `"modelsAPIEnabled": true,` if
`"modelConfiguration"` is set in the site config. For context,
`"modelConfiguration"` is a new site config field, which is not used
anywhere before this PR, and has this description:
> BETA FEATURE, only enable if you know what you are doing. If set, Cody
will use the new model configuration system and ignore the old
'completions' site configuration entirely.
I will send a change to the client logic next so that it uses this
`modelsAPIEnabled` field instead of the client-side feature flag
`dev.useServerDefinedModels`.
---
Finally, f52fba342dd2e62a606b885802f7f6bc37f4f4ac and
bde67d57c39f4566dc9287f8793cb5ffd25955b3 make a few site config changes
that @chrsmith and I discussed to enable Self-hosted models support.
Specifically, it makes it possible to specify the following
configuration in the site config:
```
// Setting this field means we are opting into the new Cody model configuration system which is in beta.
"modelConfiguration": {
// Disable use of Sourcegraph's servers for model discovery
"sourcegraph": null,
// Configure the OpenAI-compatible API endpoints that Cody should use to provide
// mistral and bigcode (starcoder) models.
"providerOverrides": [
{
"displayName": "Mistral",
"id": "mistral",
"serverSideConfig": {
"type": "openaicompatible",
"endpoint": "...",
"accessToken": "...",
},
},
{
"displayName": "Bigcode",
"id": "bigcode",
"serverSideConfig": {
"type": "openaicompatible",
"endpoint": "...",
"accessToken": "...",
},
},
],
// Configure which exact mistral and starcoder models we want available
"modelOverridesRecommendedSettings": [
"bigcode::v1::starcoder2-7b",
"mistral::v1::mixtral-8x7b-instruct"
],
// Configure which models Cody will use by default
"defaultModels": {
"chat": "mistral::v1::mixtral-8x7b-instruct",
"fastChat": "mistral::v1::mixtral-8x7b-instruct",
"codeCompletion": "bigcode::v1::starcoder2-7b",
}
}
```
Currently this site config is not actually used, so configuring
Sourcegraph like this should not be done today, but this will be in a
future PR by me.
@chrsmith one divergence from what we discussed.. me and you had planned
to support this:
```
"modelOverrides": [
{
"bigcode::v1::starcoder2-7b"": {
"useRecommendSettings": true,
},
"mistral::v1::mixtral-8x22b-instruct": {
"useRecommendSettings": true,
},
}
],
```
However, being able to specify `"useRecommendSettings": true,` inside of
a `ModelOverride` in the site configuration means that all other
`ModelOverride` fields (the ones we are accepting as recommended
settings) must be optional, which seems quite bad and opens up a number
of misconfiguration possibilities.
Instead, I opted to introduce a new top-level field for model overrides
_with recommended settings_, so the above becomes this instead:
```
"modelOverridesRecommendedSettings": [
"bigcode::v1::starcoder2-7b",
"mistral::v1::mixtral-8x7b-instruct"
],
```
This has the added benefit of making it impossible to set both
`"useRecommendSettings": true,` and other fields.
I will make it a site config error (prevents admins from saving
configuration) to specify the same model in both `modelOverrides` and
`modelOverridesRecommendedSettings` in a future PR.
---
## Test plan
Doesn't affect users yet. Careful review.
## Changelog
N/A
---------
Signed-off-by: Stephen Gutekanst <stephen@sourcegraph.com>
This is a legacy of previous self-serve-billing attempts, and is no
longer used or necessary, with the presence of the dotcom-wide
subscriptions management pages. If we want a self-serve UI for
Enterprises in the future, it should be part of the Enterprise Portal UI
project.
I asked the 3 most active users of this page, as indicated by V2
telemetry, all of whom were internal, about this and they confirmed it's
not used:
https://sourcegraph.slack.com/archives/C05GJPTSZCZ/p1720474215464999https://redash.sgdev.org/queries/854
For now, this is one less thing for us to maintain and migrate for
https://linear.app/sourcegraph/issue/CORE-100
## Test plan
CI, `sg start dotcom` -> user profile page no longer shows the
subscriptions tab
