-
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
Introduce Task API #2086
Introduce Task API #2086
Conversation
@marcdumais-work |
@azatsarynnyy Sounds awesome! I will have to juggle this review and a few other things, but I am interested for sure. |
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 Artem,
I have started reviewing. Looks very good so far. A few minor comments. I will continue the review tomorrow.
@@ -1,6 +1,7 @@ | |||
# Change Log | |||
|
|||
## v0.3.12 | |||
- Task API. Note, the format of tasks.json has been changed. For details, see the Task extension's README.md. |
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.
+1 : definitely worthy of mention; thanks for remembering to update this!
packages/task/README.md
Outdated
|
||
*cwd*: The current working directory, in which the task's command will execute. This is the equivalent of doing a "cd" to that directory, on the command-line, before running the command. This can contain the variable *${workspaceFolder}*, which will be replaced at execution time by the path of the current workspace. If left undefined, will by default be set to workspace root. | ||
*type*: determines what type of process will be used to execute the task. Can be "process" or "shell". Terminal processes can be shown in Theia's frontend, in a terminal widget. Raw processes are run without their output being shown. |
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.
In the third and fourth sentences, probably at least update "Terminal" and "Raw" to "shell" and "process".
@@ -41,16 +37,14 @@ | |||
}, | |||
{ | |||
"label": "list all files", | |||
"processType": "terminal", | |||
"type": "terminal", |
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.
"shell" instead of "terminal"?
I've corrected the docs and changed a visibility of all properties of the TerminalWidget to protected for better extendibility. |
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.
Very nice, clean code and it works nicely on Linux. Have you had the chance to try it on Windows? The unit tests pass in any case.
Just a couple of minor comments for your consideration.
@@ -0,0 +1,179 @@ | |||
/* | |||
* Copyright (C) 2018 Red Hat, Inc. and others. |
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 seems that the bulk of the code in this new file was copied from task-server.ts
. Maybe the original (Ericsson) copyright header should be preserved? I have seen a couple of other cases in this PR, where I had the same question, but it was not so clear-cut (i.e. some code copied, but good amount of original code added).
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.
Yes, you're right. Those files you mentioned were actually reworked. I've changed the copyright headers to Ericsson. Thanks for noticing that.
const taskType = taskConfiguration.type; | ||
const runner = this.runnerRegistry.getRunner(taskType); | ||
if (!runner) { | ||
return Promise.reject(new Error(`No corresponding Runner found for the Task type ${taskType}`)); |
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 might be nice to have a unit test that covers this case here, where a task runner is not found
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.
Actually, this is a leftover from the previous version when there wasn't a default runner. I removed that code and added a test to check that a default runner is used.
@azatsarynnyy is it your intention to submit the npm task resolver and provider, show in the video above, for review next? Looks lt will be awesome for JS/TS development in Theia. |
6b1617d
to
d550794
Compare
Signed-off-by: Artem Zatsarynnyi <[email protected]>
d550794
to
c2f6835
Compare
@marcdumais-work I've addressed your last comments: updated the license headers and added a test. Also merged with the latest changes from the master branch.
Unfortunately, I don't have a chance to try it on Windows. |
Marc, thank you for taking the time to try that changes and reviewing my PR. |
This PR closes #1698 by introducing the Task API.
One of the interesting advantages of the Task API is that it allows Theia to consume VSCode's tasks.json.
The main concepts are:
Task Type
A Task Type is used to define which Task Resolver, Task Provider or Task Runner should be used with a particular Task Configuration.
Task Resolver (frontend contribution point)
Resolves a Task Configuration before sending it for execution to the Task Server. For example, this makes it possible to hide the actual complex command line from the user.
Task Provider (frontend contribution point)
It allows an extension to contribute the Tasks programmatically to the system.
Task Runner (backend contribution point)
A Task Runner knows how to run and kill a Task of a particular type. If contribution provides a Task Runner then it will be used to run a Task of a particular type otherwise, the default Task Runner is used.
That contribution point won't be so widely used as a Task Resolver and a Task Provider. But it's necessary for the extensions like Che, whose Tasks aren't running as the processes on Theia backend.
The Task extension provides
ProcessTaskRunner
implementation that can run a Task as a process or a command inside a shell (Tasks of typeprocess
orshell
). It also serves as a default runner.Here are some demos of using the Task API
Running a Task from the VSCode sources:
1/ Just open VSCode repo as Theia workspace and copy the tasks.json from .vscode into .theia folder.
2/ Now you can run, for example,
Run tests
task.Theia npm extension (not a part of this PR) that contributes:
Che Task extensions (not a part of this PR) that contributes: