-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for compound launches #11444
Add support for compound launches #11444
Conversation
@colin-grant-work It would help us a lot, if this could make it to the upcoming release. So if you have some cycles, we would be very thankful for a review. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Functionality-wise this looks already quite good. I have a few comments on the code though.
@msujew Thank you very much for your fast and detailed review! I added another commit to it so you can see the changes but I can also squash them if you feel everything is taken care of. |
for (const configData of compound.configurations) { | ||
const name = typeof configData === 'string' ? configData : configData.name; | ||
if (name === compound.name) { | ||
throw new Error(nls.localize("Launch configuration '{0}' contains a circle with itself", name)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This NLS call needs a key
nls.localize(key: string, message: string, ...interpolations: string[])
. This call just has the message
and one interpolation
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good catch! I added the missing key to it, thank you!
private stopEmitter = new Emitter<void>(); | ||
onDidSessionStop = this.stopEmitter.event; | ||
|
||
sessionStopped(): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename to stopSession
. sessionStopped
sounds like a check, not an action.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simply used the same name as in VS Code but I agree that stopSession
is a better name.
|
||
import { TaskIdentifier } from '@theia/task/lib/common'; | ||
|
||
export const defaultCompound: DebugCompound = { name: 'Compound', configurations: [] }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appears to be unused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I defined it and forgot to use it in the schema updater but now it is used there.
@colin-grant-work Thank you very much for your review! I pushed it as a separate commit so you can see the changes at a glance. If need be, I can squash the changes and push the whole thing again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martin-fleck-at something to try but I was unable to successfully start the Launch Electron Backend & Frontend
debug configuration. The electron window did spawn but from the main window (where the config was launched from) I was not able to interact with the debug session (ex: stop it) since it did not seem to exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's looking good !!
I am not sure if the following is related but
When I start a debug session (Browser Backend and Frontend), I am getting the following errors (TextEditor is disposed!) as per the image.
My setup is a theia
electron app. debugging theia
on browser running a 'hello_express' project). The two theia
workspace folders are different.
@vince-fugnitto @alvsan09 Thank you very much for your input! I tested it a few times with The only one that sometimes causes problems is the For simple cases everything seems to work as expected, e.g.,
I think it may has to do with how the debug adapters and their environment are set up or maybe it is a timing issue and some launch configurations need to wait for others to be completely started? I checked the VSCode code and there they also don't have any special waiting mechanism, they simply use @alvsan09 Unfortunately, I cannot reproduce the |
@colin-grant-work Could you please have a look if you believe the reported issues are connected to this PR or some other setup issue that is only revealed through this PR? I already tested it with the pre-built Gitpod but I am not sure how else I can proceed here so any help would be greatly appreciated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested running the updated code base to run a different Theia
repository, and there is one combination as show below that causes errors.
I don't think it's related to this change but it would be great if all combinations below could work:
NOTE: I have also changed the configurations so theia
runs 'pwa-chrome' instead of 'chrome'
Running Theia updated on browser,
then spawning Theia on electron
=== WORKS FINE ====
Running Theia
updated on electron,
Changing electron launch backend config to: --remote-debugging-port=9223
Changing to port: 9223 on Attach to Electron Frontend
then spawning Theia
on electron, gives different errors and ultimately crashes.
=== FAILURES ====
Running Theia
updated on electron,
then spawning Theia
on browser
=== WORKS FINE ===
Running Theia
updated on browser,
Changing ports on backend / frontend launch configs.
then spawning Theia on browser
=== WORKS FINE ===
@alvsan09 Thank you for your in-depth analysis! I agree that starting another Theia instance from Electron seems to cause a problem with the plugin host. When I start the debug session I can see that the new Electron window opens normally and everything seems fine but after some time the 'Attach to Plugin Host' reports the following problem in the original window: Still I would argue that this is a problem specifically to the plugin host, so maybe this could be considered as a separate bug? |
I just checked and the problem with 'Attach to Plugin Host' also happens when I start all three launch configurations manually. I therefore created a new bug for it here: #11475. I think I addressed all other comments so far so is there any chance we can still get this merged before the release? An adopter would really appreciate that. |
Hi @martin-fleck-at , I just saw the following problem, when toggling |
@alvsan09 Oh wow, great catch, thank you! Seems like I removed something when updating the current configuration and so changed properties were not correctly applied. |
@martin-fleck-at, |
@alvsan09 Oh wow, you are right! I am very sorry for missing that! Seems like the typeguards were not good enough to detect a dynamic configuration vs a regular configuration. I just checked whether the property was there but not if that property was set. |
@martin-fleck-at , |
@alvsan09 I updated the search for the current configuration again, I think now all cases should be covered. Thank you very much for taking the time! |
@martin-fleck-at ,
See the |
- Extend debug model for compound launches -- Support pre-launch task, stopAll, list of configurations -- Properly parse compounds into configuration model -- Support mapping to custom session option type -- Support search of options by configuration, compound, and name - Show compound launches in configuration dropdown -- Query all available options -- Use JSON (de-)serialization to allow multiple options with same name --- Previously custom string was used for identification - Extend session manager to start compound session options - Ensure compound sessions can also be found from DebugMain Fixes #11302 Signed-off-by: Martin Fleck <mfleck@eclipsesource.com>
- Use 'unknown' in type guard - Simplify parsing code for debug configuration model - Deprecate use of custom debug session options parsing - Remove unnecessary overload method in debug configuration manager
- Ensure proper NLS usage - Use default constant for schema updater - Rename 'sessionStopped' to 'stopSession'
- Localize further fields in debug schema - Move optional provider type to configuration type - Create custom dynamic options type for convenience
@alvsan09 Thank you again for your feedback!
Could you please give it another try? I don't know what could have caused this but I cannot reproduce it at all. What browser are you using? |
@martin-fleck-at ,
For the two remaining issues, I managed to reproduce them using a mult-root workspace, and the amount of entries in the configuration is larger e.g.. all the ones provided by theia + all the ones provided by the The following clip shows the difference when having a folder vs a workspace project. multi-root-debug-view-issues.mp4 |
- Prefer select options rendering to bottom in most cases - Using 'Add Configurations' in dropdown triggers focus-lost on pick service automatically closing the workspace selection, keep picking open
@alvsan09 With the multi-root workspace service I can indeed reproduce the problem! Seems like when we need to select a workspace the update of the configurations dropdown takes focus and automatically closes the workspace select, I now keep it open even on focus lost. As for the rendering "issue": This really depends on how much space is available at the top or bottom. Previously, if there was not enough space at the bottom, it was rendered to the top. I changed that so that it prefers bottom rendering unless more content can be shown when rendering to the top. Hopefully this will resolve the remaining issues. In any case, I really appreciate you sticking with me on this ;-) |
@martin-fleck-at The video starts showing a set of dynamic launch configurations which were created on a previous session with duplicating_dynamic_launch.mp4I saw a strange behaviour once before where a non dynamic config. managed to get inserted among the recent dynamic configurations, I am not sure how to reproduce it, although I managed to get a screen shot of the serialized data. See |
@msujew, Do you agree with the change of approach affecting the custom |
@alvsan09 @martin-fleck-at Yeah, the changes look reasonable to me. Everything in regards to the select component still works as expected or even better 👍 |
- Option name property was missing when restoring data - Fix proper update of current value -- Current value is not always perfectly in list of options due to serialization so we do a matching first
@alvsan09 I hope I managed to remove the last issues now. When restoring the old dynamic configurations I now ensure that the options name is properly derived if it is not set already. I also filter for dynamic options to ensure nothing else gets into that list (even though I was not able to reproduce that locally). Interestingly, the fix showed an issue which probably was the reason for the initial custom serialization: When we set the current value in the debug session manager, the value we have in current does not necessarily match exactly one of the options we have on the configuration drop down, mostly due to the fact that properties are in different order. So I now aim to match the current value to the current option before when updating the select. As far as I can tell, this now works for all option types and updates in the launch.json are also properly considered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @martin-fleck-at ,
I have done a full regression and it looks almost there !
I found the issue shown on the video clip below, where dynamic configurations are not restored as current, from local storage.
I have also added a question as an inline comment.
failing_to_restore_dynamic_to_current.mp4
const dynamicOptions = options.map(option => { | ||
option.name = option.name ?? option.configuration.name; | ||
return option; | ||
}).filter(DebugSessionOptions.isDynamic); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it really necessary to filter for isDynamic
?
non dynamic configs should not be available under the received argument:
options?: DynamicDebugConfigurationSessionOptions[]
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are absolutely correct that it should not be necessary. I added this guard because you had the case where there was a regular configuration in the 'recentDynamicOptions'. I could not reproduce the case but during runtime we already have a type guard before updating recently used dynamic options so I reasoned that it probably was caused during loading some old data. Since the recent options are limited to 3, I thought the extra safety outweighs any potential performance cost. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am leaning towards removing it, as the case may have been caused while switching among different versions of this change.
If we ever see it again, it's not too bad for the user to ignore it or replace it by making a new selection, and then we could try to fix the actual source of the problem.
Using the last commit I have verified that the functionality works as expected ! 👍 @vince-fugnitto and @colin-grant-work, any pending items on your side ? I have successfully run the tests below:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have any objections to the changes 👍
I believe Alvaro reviewed thoroughly #11444 (comment).
@colin-grant-work @msujew Any objections to merging this? |
None from me. |
What it does
Fixes #11302
Extend debug model for compound launches
-- Support pre-launch task, stopAll, list of configurations
-- Properly parse compounds into configuration model
-- Support mapping to custom session option type
-- Support search of options by configuration, compound, and name
Show compound launches in configuration dropdown
-- Query all available options
-- Use JSON (de-)serialization to allow multiple options with same name
--- Previously custom string was used for identification
Extend session manager to start compound session options
Ensure compound sessions can also be found from DebugMain
I tried to keep backwards compatibility with interfaces and parameters as good as possible.
How to test
Launch Electron Backend & Frontend
andLaunch Browser Backend & Frontend
. But you can also add your own compound launches and play around with the options (stopAll, preLaunchTask).Review checklist
Reminder for reviewers