mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 19:21:50 +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> |
||
|---|---|---|
| .. | ||
| __mocks__ | ||
| bookmarklet | ||
| dev | ||
| dist | ||
| src | ||
| tests-examples | ||
| .bazelignore | ||
| .eslintignore | ||
| .stylelintrc.json | ||
| BUILD.bazel | ||
| bundlesize.config.js | ||
| package.json | ||
| README.md | ||
| statoscope | ||
| tsconfig.json | ||
| vitest.config.ts | ||
Web Application
Local development
Use sg CLI tool to configure and start local development server. For more information check out the sg documentation.
Our local development server runs by starting both a Caddy HTTPS server and a Node HTTP server. We then can reverse proxy requests to the Node server to serve client assets under HTTPS.
Configuration
Environment variables important for the web server:
WEB_BUILDER_SERVE_INDEXshould be set totrueto enable serving of an index page.SOURCEGRAPH_API_URLis used as a proxied API url. By default it points to the https://k8s.sgdev.org.
It's possible to overwrite these variables by creating sg.config.overwrite.yaml in the root folder and adjusting the env section of the relevant command.
Development server
sg start web-standalone
Public API
To use a public API that doesn't require authentication for most of the functionality:
SOURCEGRAPH_API_URL=https://sourcegraph.com sg start web-standalone
Production server
sg start web-standalone-prod
Web app should be available at https://${SOURCEGRAPH_HTTPS_DOMAIN}:${SOURCEGRAPH_HTTPS_PORT}. Build artifacts will be served from <rootRepoPath>/client/web/dist.
Note: If you are unable to use the above commands (e.g. you can't install Caddy), you can use sg run web-standalone-http instead. This will start a development server using only Node, and will be available at http://localhost:${SOURCEGRAPH_HTTP_PORT}.
API proxy
In both environments, server proxies API requests to SOURCEGRAPH_API_URL provided as the .env variable.