Skip to content
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

Discussion of the demo: Running VS Code tasks as remote tasks #18060

Closed
RomanNikitenko opened this issue Oct 6, 2020 · 1 comment
Closed
Labels
area/editor/theia Issues related to the che-theia IDE of Che area/plugins kind/question Questions that haven't been identified as being feature requests or bugs. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. severity/P2 Has a minor but important impact to the usage or development of the system.

Comments

@RomanNikitenko
Copy link
Member

Summary

The issue is for discussion, so I added "question" label.

Yesterday was Che community meeting and there was demo "Running VS Code tasks as remote tasks - PoC".
The video was placed here: https://youtu.be/BUVObxKON3Y

At the moment we have an ability to run che tasks as remote tasks, but we don't have such opportunity for other tasks, like: shell, typescript, npm, gradle, ...

For che tasks we register che task runner + che task resolver + using remote terminals for output.
Finally, che task configuration is executed by machine exec.

On my demo the idea was to apply the same approach for VS Code tasks:

  • using single task runner, resolver and remote terminals for che and vs code tasks as well
  • so any task is considered as remote task and is executed by machine exec
  • it's most likely that we don't need type che for tasks anymore - it could be just shell task type which present in theia and vs code model.

I didn't see how this approach could be applied previously due to some difficulties related to management of running tasks process and terminal creation from plugin side (Historically we have task plugin, not extension, please see a description for the issue: #11458).
Within eclipse-che/che-theia#742 I had to move some logic to plugin-ext side, as result we got more flexibility for terminals creation management. Recently I played a little with tasks within Hack and Hustle days and now I see that in general we could apply described above approach (though it would be nice to land #16893 first 🙂)

In my draft implementation (please see video https://youtu.be/BUVObxKON3Y ) I faced with mapping problem: how we should match task type to a container for running (for example, which container should be used for running npm or typescript vs code task). I implemented the simplest way - just ask user to select a container at running a task. Also automatically detection that for running a typescript task can be used component with typescriptalias was implemented.

But it's still question for me about expected behavior:

  • remember user's choice for single task (VS Code has similar behavior for problem matchers)
  • remember user's choice for task type
  • some menu item for ability to map task type to component
  • mapping section on devfile level
  • mapping on preference level
  • any other ideas?

Another question - what VS Code tasks and related extensions we are going to support.
For example, I tested my changes for typescript and npm tasks. Within testing I found that typescript is not installed in the container with typescript plugin.
Also I tried to test tasks from https://open-vsx.org/extension/richardwillis/vscode-gradle extension and found some API incompatibility problems (CustomExecution API), some changes are required on theia side to have it running for che.
So it would be nice to have such list of extensions for testing at any implementation.

In the meeting where the demo was shown @l0rd mentioned another approach related to running tasks, so I created this issue not as task which we are going to implement, but as discussion - to share my current thoughts about task system, to get thoughts other people in one place and so on.

@RomanNikitenko RomanNikitenko added the kind/question Questions that haven't been identified as being feature requests or bugs. label Oct 6, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Oct 6, 2020
@RomanNikitenko RomanNikitenko added area/editor/theia Issues related to the che-theia IDE of Che area/editors area/plugins and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. area/editors labels Oct 6, 2020
@benoitf benoitf added the severity/P2 Has a minor but important impact to the usage or development of the system. label Oct 7, 2020
@che-bot
Copy link
Contributor

che-bot commented Apr 6, 2021

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 6, 2021
@ericwill ericwill added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/editor/theia Issues related to the che-theia IDE of Che area/plugins kind/question Questions that haven't been identified as being feature requests or bugs. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. severity/P2 Has a minor but important impact to the usage or development of the system.
Projects
None yet
Development

No branches or pull requests

4 participants