Conversation
…ofile VS Code only creates a named profile when it opens a window. CLI calls such as --install-extension merely look the profile up and abort with "Profile '<name>' not found". Since the plugins were installed from postInstall, i.e. before VS Code was ever launched, every plugin installation failed on a fresh profile. Vscode now checks whether the profile already exists and defers the plugin installation until after the IDE has been launched if it does not. Once the profile exists the established order is kept so the plugins are active right away. Also corrected the comment claiming that a profile isolates authentication: VS Code keeps the auth sessions in the OS keyring and shares them across all profiles.
quando632
added
vscode
Coverage Report for CI Build 35725900551Coverage increased (+0.03%) to 74.168%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions24 previously-covered lines in 2 files lost coverage.
Coverage Stats
💛 - Coveralls |
The plugin marker files live per IDEasy project while the plugins of VSCode belong to a profile. A profile that VSCode has just created is empty, so the marker files cannot tell whether a plugin is present in it. Enabling VSCODE_PROFILE_ENABLED in an existing project therefore left the user with an IDE without any plugin: the new profile is empty, but every plugin was skipped as already installed. IDEasy reported success and asked for a window reload that changed nothing. PluginBasedCommandlet now offers isForcePluginInstallation() as an extension point for the marker file check and reports how many plugins were installed. Vscode overrides the extension point while installing into a profile it has just created, and only asks for the reload when something was installed.
|
Thanks for the PR, the tests are clearly passing so no issues there. I was wondering on the choice of waiting 30 times, 1 seconds each, is there a particular reason for this choice or is it just a "hunch"? I wonder if it could be lowered or if there is an argument to increasing it. Just a curiosity/nitpick, and also asking in case there are other similar cases in IDEasy. After the changelog addition I would still move to Reviews |
|
|
||
| // A profile that VSCode has just created is empty. Our plugin marker files live per project while the plugins of VSCode belong to a profile, so the marker | ||
| // files cannot tell whether a plugin is present in the new profile. Without this the user ends up with an empty IDE. See issue #2471. | ||
| return this.installingIntoNewProfile || super.isForcePluginInstallation(); |
There was a problem hiding this comment.
installingIntoNewProfile is set true whenever plugins are being installed into a freshly created profile.
Suggestion: instead of reinstalling everything, could we check the actual plugin list VS Code has and only install what's missing?
There was a problem hiding this comment.
I like the idea, but in this PR it would not change the outcome: the flag is only set while installing into a profile that VS Code has just created, and such a profile is empty, so every plugin is missing anyway. Checking the real extension list instead of the marker files would be more robust in general, for example when a user resets the profile or the profile creation times out while old marker files exist. However, it changes how PluginBasedCommandlet decides what is installed for all IDEs, including id matching and pinned versions. I would prefer to do that in a follow-up issue, if that is fine with you. Shall I open one?
…st 20 s The profile check reused the process context of the plugin installation, which throws and logs on a non-zero exit code. Every check before VSCode had created the profile was therefore reported as an error. It also treated any failure as a missing profile, so a broken VSCode made IDEasy poll until the timeout. The check now uses its own process context without error handling and only considers the profile missing if VSCode names it on stderr. Any other failure is reported with the output of VSCode: before the launch the plugins are installed as usual so the real error surfaces, after the launch the wait stops immediately. The wait is bounded by a wall clock deadline of 20 s instead of 30 attempts, since each attempt spawns VSCode itself, and the user is informed while IDEasy waits.
|
Thanks both for the review! @MeShehi, the 30 x 1 s was an upper bound picked by feel, not a measured value. In my end to end runs the profile showed up on the second check, roughly 2 s after launch. The count based loop could also take much longer than 30 s, since every check spawns Regarding the CHANGELOG: I left it out on purpose, see the note at the end of the PR description. #2058 is still behind the |
4 participants
This PR fixes #2471
Implemented changes:
Vscodeno longer installs the plugins before VS Code has created its profile.VS Code only creates a named profile when it opens a window. From
code --help:As soon as
--install-extension(or--list-extensions/--uninstall-extension) is passed, VS Code takes the extension management code path instead: the folder argument is ignored, no window is opened, and the profile is only looked up. If it does not exist, VS Code aborts withProfile '<name>' not found.and exit code 1.Since the plugins are installed from
postInstall(), i.e. before VS Code is ever launched, every plugin installation failed on a fresh profile whileVSCODE_PROFILE_ENABLED=true.installPlugins(...)now checks whether the profile already exists. If it does not, the plugins are deferred and installed after the IDE has been launched, once the profile shows up (checked once per second for at most 20 s, with an info message while IDEasy waits). The profile is only considered missing if VS Code names it on stderr (Profile '<name>' not found.). Any other failure of VS Code is reported with its output instead: before the launch the plugins are installed as usual so the real error surfaces, after the launch the wait stops immediately. If the profile already exists, every run after the first, so the established order is kept, so the plugins are active right away.The plugin marker files live per IDEasy project while the plugins of VSCode belong to a profile. A profile that VSCode has just created is empty, so the marker files cannot tell whether a plugin is present in it. Enabling the toggle in an existing project therefore left the user with an IDE without a single plugin: the new profile is empty, but every plugin was skipped as already installed, IDEasy reported success and asked for a window reload that changed nothing.
PluginBasedCommandletnow offersisForcePluginInstallation()as an extension point for the marker file check and reports how many plugins were installed.Vscodeoverrides it while installing into a profile it has just created, and only asks for the reload when something was actually installed. The default behaviour of all other IDE commandlets is unchanged.Also corrected a code comment claiming that a profile isolates authentication. It does not: VS Code keeps auth sessions in the OS keyring and shares them across all profiles (see the analysis in #2058).
Testing instructions
Verified end to end against a real VS Code 1.137.0 on Windows 11, with
VSCODE_PROFILE_ENABLED=true, a profile that did not exist yet and no plugin marker files. The observed order ofcode.cmdinvocations was:--list-extensions— fails, profile does not exist, plugin installation is deferred--list-extensions— still failing on the first poll--list-extensions— succeeds on the second poll--force --install-extension …for every pluginResult: 39 of 39 plugins installed, 0 failures. Before this change the same scenario failed 39 out of 39 times with
Profile '...' not found.A second run was done with the marker files deliberately left in place, which is what a user enabling the toggle in an existing project actually has: 38 plugins installed, 0 failures, 0 skipped because of a marker file, and the freshly created profile ended up with 62 extensions. Before this change that exact scenario produced a profile with 0 extensions while IDEasy reported success.
Step 4 below was not exercised in those runs; the "profile already exists" path was only observed separately in another workspace.
mvn -pl cli test -Dtest=VscodeTestSix cases are covered:
testPluginsAreInstalledBeforeLaunchByDefault: toggle disabled, established order unchangedtestPluginsAreInstalledAfterLaunchIfProfileEnabled: toggle enabled, profile missing, plugins installed after the launchtestPluginsAreInstalledBeforeLaunchIfProfileAlreadyExists: toggle enabled, profile present, established order kepttestPluginsAreInstalledIntoNewProfileDespiteExistingMarkerFiles: plugins installed into the new profile although their marker files existtestPluginsAreNotDeferredIfVscodeFailsForAnotherReason: VS Code fails for another reason, plugins are not deferred and the cause is reportedtestDeferredPluginsAreSkippedIfVscodeFailsAfterLaunch: VS Code fails after the launch, waiting stops on the first unexpected failureEnd to end with a fresh profile:
VSCODE_PROFILE_ENABLED=truein$IDE_HOME/conf/ide.propertiesideasy-«project»-«workspace»does not exist yet$IDE_HOME/.ide/plugin.vscode.*— this is the realistic case when enabling the toggle in an existing projectide vscodeExpected: VS Code starts, then all active plugins are installed and a message asks for a window reload. Verify that the new profile really contains them:
code --profile=ideasy-«project»-«workspace» --extensions-dir=$IDE_HOME/plugins/vscode --list-extensionsBefore this PR every plugin failed with
Profile '...' not found., and with the previous commit alone the profile would have stayed empty because of the marker files.Run
ide vscodea second time.Expected: unchanged behaviour, nothing is reinstalled, no reload message.
Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»In Progressand assigned to you or there is no issueinternalpom.xmlfiles or otherwise if runtime dependencies changed, you have updated our LICENSE.asciidocOn the two unchecked items: