Merge main 2025-04-01 #4938
Closed
Merge main 2025-04-01 #4938
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ConfigHandler.updateIdeSettings() was largely ineffective because the ideSettingsPromise was stored in the ProfileLoader object, so updating to a new ideSettingsPromise resulted in the config being reloaded with the old settings. Fix this by passing the ideSettingsPromise as a parameter to IProfileLoader.doLoadConfig().
Instead of *writing* out a default configuration, write an empty configuration and dynamically merge the users edits into our default configuration; the idea is that our default configuration can be autogenerated depending on our current recommended models, IDE settings, machine capabilities. The goal is that it will be seldom necessary to manually edit the config.
The localModelSize config setting is used to select between two different default configurations - one for smaller machines, one for larger machines.
continue.toggleFullScreen: not all that useful, works poorly continue.openConfig: editing the JSON should be unusual, not usual continue.signInToControlPlane, continue.openAccountDialog: not needed for Granite.Code
Switch the small and large models to use granite3.1-dense; update contextLength to 128k, and maxTokens to 128k/4 == 32k.
In a27ea8b Granite-Code: merge user config into a default configuration the handling was accidentally changed to console.log() the error (with an incorrect log message.)
This command overwrites the upstream ~/.continue/config.json (or extension/.continue-debug/config.json) with the merge of the current autogenerated configuration with the user's ~/.granite-code/.config.json. The purpose of this is to allow a Granite.Code contributor to switch to the upstream Continue extension while working on an upstream feature.
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
From Fred Bricon <fbricon@gmail.com>
Use the full nomic-embed-text:latest to be consistent with the name we use in the Paver UI code.
Import the Paver code for setting up Ollama and the Granite Models into the extension without adaption other than to get it to build and run within the Continue plugin. The granite.setup command will open a Webview with the Continue GUI.
Return a function that can be used to remove the listener.
Using 128k context length causes excessive memory usage. (41.5 GB for granite-3.1-dense:2b running on the CPU) - drop the default context length to 16k.
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
* Remove model selection - instead the model we show status for is based on what's in the Continue configuration. * Remove the step to write a new Continue configuration. * Lightly adapt text
Enable CI checks for PR's and pushes to granite/customization and granite/integration. The jetbrains tests are disabled, since we don't care about that at the moment.
While we know that we'll always create the component with value being one of the options, tsc doesn't, so put some handling in for this case.
…el list The e2e tests set up a config.json which has a dummy LLM as first in the model list. When we merge that with our default models, the granite models end up first, and are used by the tests instead of what is intended.
The SSH test requires a host to be running permanently with SSH_HOST/SSH_KEY set as secrets; if these secrets are not set, then exclude it.
For Granite.Code, we care only about local models, so rather than configuring API keys for all the different LLMs in our CI, just skip the tests.
Improve branding
getIdeSettingsSync() was made private.
If we only set the VSCODE_VERSION when running 'extest get-vscode', then we might get a version of chromedriver that is incompatible with the version of vscode we download.
Signed-off-by: Fred Bricon <fbricon@gmail.com>
There are some minor style problems in the setup wizard related code. - Some of the imports are in the wrong order - Not all lines wrap properly This commit addresses those problems by running the code through Prettier and letting it figure it out. Signed-off-by: Fred Bricon <fbricon@gmail.com>
The setup wizard needs to know how much disk is available on the user's system so it can inform the user if there is insufficient disk space to download the (rather large) Granite models. The code currently does this using the systeminformation module to check the available space on the root filesystem. That isn't exactly correct, though, because models are stored in the users directory, which may be on a different filesystem altogether. Furthermore, systeminformation doesn't handle btrfs systems properly, since it keys output off the volume name, and the volume name is shared between subvolumes with btrfs. This commit addresses both problems by switching the code over to use the check-disk-space module, which is more form fit for our purposes anyway. Signed-off-by: Fred Bricon <fbricon@gmail.com>
The setup wizard reports to the user if there is insufficent diskspace to download the Granite model the user has selected. If there is insufficient diskspace to proceed it stops the user from continuing. Unfortunately, there is a oversight in the code where it fails to consider that the user may already have a model downloaded. In that case, the model doesn't need new diskspace. This commit fixes that problem by reporting the download status of each model to the wizard and then ignoring already downloaded models when calculating diskspace needs. Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
when the open tutorial command is invoked, typically by the Granite.Code setup wizard, we need to open a Granite.Code specific tutorial, instead of the original one, that mentions Continue and links to the continue website Signed-off-by: Fred Bricon <fbricon@gmail.com>
Signed-off-by: Fred Bricon <fbricon@gmail.com>
Disable irrelevant continue features
We were previously keying this off of hubEnabled, but that doesn't make sense in the code now since there can be multiple local assistants/profiles.
In config/index.ts, hubEnabled = false was treated as "using Continue for teams rather than the hub.continue.dev", but for us, neither is true - so just remove the message "You are using Continue for teams".
…ents Remove (or reremove) elements that we don't want
This merge temporarily removes: - customization of the UI to remove irrelevant elements - adding the granite models to the configuration after loading
✅ Deploy Preview for continuedev ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
yikes, sorry! Wrong remote, closing! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This merges in the current origin/main -
Because the upstream has a bunch of UI changes that conflict with our customization and config changes, this merge temporarily reverts:
Once this passes CI and I merge it, I'll do a follow-on pull request that adds new versions of these back.