mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 17:51:57 +00:00
12b0e4e233
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> |
||
|---|---|---|
| .. | ||
| aws_codecommit.schema.json | ||
| azuredevops.schema.json | ||
| batch_spec.schema.json | ||
| bitbucket_cloud.schema.json | ||
| bitbucket_server_util.go | ||
| bitbucket_server.schema.json | ||
| bitbucketcloud_util.go | ||
| BUILD.bazel | ||
| changeset_spec.schema.json | ||
| extension_schema.go | ||
| gerrit.schema.json | ||
| github_util.go | ||
| github.schema.json | ||
| gitlab_util.go | ||
| gitlab.schema.json | ||
| gitolite.schema.json | ||
| go-modules.schema.json | ||
| json-schema-draft-07.schema.json | ||
| jvm-packages.schema.json | ||
| npm-packages.schema.json | ||
| onboardingtour.schema.json | ||
| opencodegraph-protocol.schema.json | ||
| opencodegraph.schema.json | ||
| other_external_service.schema.json | ||
| package.json | ||
| pagure.schema.json | ||
| perforce.schema.json | ||
| phabricator.schema.json | ||
| python-packages.schema.json | ||
| README.md | ||
| ruby-packages.schema.json | ||
| rust-packages.schema.json | ||
| schema.go | ||
| settings.schema.json | ||
| site.schema.json | ||
| stringdata.go | ||
| tsconfig.json | ||
| validation_test.go | ||
Sourcegraph JSON Schemas
JSON Schema is a way to define the structure of a JSON document. It enables typechecking and code intelligence on JSON documents.
Sourcegraph uses the following JSON Schemas:
Modifying a schema
- Edit the
*.schema.jsonfile in this directory. - Run
bazel run //schema:write_generated_schema. - Commit the changes to both files.
- Run
sg startto automatically update TypeScript schema files.
Known issues
- The JSON Schema IDs (URIs) are of the form
https://sourcegraph.com/v1/*.schema.json#, but these are not actually valid URLs. This means you generally need to supply them to JSON Schema validation libraries manually instead of having the validator fetch the schema from the web.