Added composite command support and test coverage by msivasubramaniaan · Pull Request #639 · che-incubator/che-code

msivasubramaniaan · 2026-01-28T13:22:10Z

What does this PR do?

This PR supports to run the composite commands in terminal

What issues does this PR fix?

eclipse-che/che#21859
eclipse-che/che#23726
eclipse-che/che#23709
eclipse-che/che#23725

How to test this PR?

Added workspace which has all commands of devfile. Run those commands from devfile.yaml.

Does this PR contain changes that override default upstream Code-OSS behavior?

the PR contains changes in the code folder (you can skip it if your changes are placed in a che extension )
the corresponding items were added to the CHANGELOG.md file
rules for automatic git rebase were added to the .rebase folder

github-actions · 2026-01-28T13:22:21Z

Click here to review and test in web IDE:

code/extensions/che-commands/package-lock.json

github-actions · 2026-01-30T13:34:25Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

rgrunber · 2026-01-30T15:43:44Z

code/extensions/che-commands/src/taskProvider.ts

+
+				// Single-component → join commands
+				const joiner = parallel ? " & " : " && ";
+				let compositeCmd = execs.map((e) => e.commandLine).join(joiner);


@RomanNikitenko , is string manipulation the only way to do this ? Using compound tasks on the vscode side still isn't possible ?

I investigated that area more than 2 years ago, so I asked @msivasubramaniaan to double check that option when he started to work on the issue.
@msivasubramaniaan could you provide result of your investigation?

I double-checked this again.

At the moment, yes — string manipulation is still the only practical way to achieve this.

VS Code does not support dynamically creating or chaining compound tasks programmatically from an extension. Compound tasks must be statically defined in tasks.json, and there’s no API to generate or invoke a compound task on the fly based on resolved components or runtime data.

Because of that limitation, joining commands using && / & (depending on parallel vs sequential execution) remains the only viable solution when the task needs to be assembled dynamically.

So the approach of building a composite command string is the only way

RomanNikitenko

@msivasubramaniaan
I tried to test the functionality using your samples
I run component-parallel-demo command:

My understanding - it should run signal-frontend in the frontend container and signal-backend in the backend container.

Actual behaviour:

there is no output for both commands, for both containers
there is just message "Composite multi-component execution completed" which comes from the taskProvider https://github.com/che-incubator/che-code/pull/639/changes#diff-e505171c2bbd2db1494bbb49e7c7ccaad44644b923a12f6c5ca2ebdedd0fdbcdR389

Moreover, the dependent commands just hanging without any output when I run them separately:

Could you clarify:

what is expected behaviour there?
is it possible to detect which component is used for your test commands?
If commands are in the running state - why composite command reports that Composite multi-component execution completed?

thanks in advance!

RomanNikitenko · 2026-02-02T21:24:19Z

@msivasubramaniaan
I've prepared own sample and tested parallel and sequential uses cases for 2 components, I can confirm - it does not work, there is a bug - no output for both dependent commands and it's unclear if the commands are executed at all:

RomanNikitenko · 2026-02-02T21:35:21Z

@msivasubramaniaan
I've detected one more bug : a command label should be displayed instead of id:

RomanNikitenko · 2026-02-05T11:53:55Z

@msivasubramaniaan
I see you've requested a new review, but image for testing is not ready.
Please let me know when you test all use cases we discussed and regressions are fixed.
Thanks!

github-actions · 2026-02-05T12:24:23Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-05T15:05:22Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-05T16:49:11Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-05T19:50:14Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

RomanNikitenko · 2026-02-24T09:50:33Z

For one composite task there are at least 3 terminals
The first one shows mixed output for all dependent task.

Let's say dependent tasks build different modules:

do we really need all mixed output in the first terminal?
how it's going to be used? I guess it's hard to find any useful information because of tons mixed logs...
wdyt?

mixed_output.mov

RomanNikitenko · 2026-02-24T10:57:58Z

Regarding dependent commands labels:

a dependent task item does not look readable - devfile: parallel-ubi8-ubi9:ubi8-tools(web-nodejs-sample)
in the current implementation each command has its own terminal - do we really need that prefix for dependent tasks? (like: parallel-ubi8-ubi9- is id of a composite task - is it required for a dependent task item?)
I propose to use command label instead of id to get it more readable, like - devfile: ubi8 container echo seems clearer than devfile: parallel-ubi8-ubi9:ubi8-tools(web-nodejs-sample)

RomanNikitenko · 2026-02-24T12:04:56Z

I think there is inconsistent behavior related to the scanning task output prompt. This prompt is not displayed when I run a simple devfile task, but it is displayed when I run a composite task.

scanning-task-output.mov

msivasubramaniaan · 2026-02-25T07:21:26Z

For one composite task there are at least 3 terminals The first one shows mixed output for all dependent task.

Let's say dependent tasks build different modules:

do we really need all mixed output in the first terminal?

how it's going to be used? I guess it's hard to find any useful information because of tons mixed logs...
wdyt?

mixed_output.mov

For a composite task running dependent tasks in parallel, there are indeed multiple terminals:

Each dependent task runs in its own terminal (isolated execution).
The first terminal shows aggregated output from all dependent tasks.

Why we keep the mixed output in the first terminal:

The composite task is treated as a single logical operation, so the main terminal provides a unified view of progress and results.
Users can monitor the overall execution without switching between multiple terminals.
It behaves similarly to many build tools (like Maven/Gradle/npm workspaces) where logs from multiple modules appear together.

How it can be used effectively:

The aggregated output is tagged by component, for example:

[backend] build started
[frontend] build started
[backend] compiling...
[frontend] bundling...
[backend] done
[frontend] done

This makes it possible to identify which component produced each log line.
If detailed debugging is needed, users can still open the individual task terminals, which contain the full isolated logs.

Why this approach is useful:

Gives a quick overview of the composite execution.
Avoids constantly switching terminals.
Preserves full logs per component when needed.

So the first terminal is intended as a high-level monitoring view, while the individual terminals remain available for detailed investigation.

RomanNikitenko · 2026-02-25T07:55:33Z

How it can be used effectively:

The aggregated output is tagged by component, for example:
[backend] build started
[frontend] build started
[backend] compiling...
[frontend] bundling...
[backend] done
[frontend] done
This makes it possible to identify which component produced each log line.

Sorry - but in the current implementation there is no aggregated output is tagged by component
So - it's not true: This makes it possible to identify which component produced each log line.

@msivasubramaniaan
I understand that there is a technical issue and you are trying to workaround it
but
if you would have a choice - would you use the mixed output or separate?

my personal opinion - there are already separate terminals for each dependent task with the corresponding output - I would not use mixed output in the third terminal...

github-actions · 2026-02-25T08:22:21Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-25T09:19:11Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-25T11:06:22Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-25T13:43:24Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-25T18:13:44Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-25T20:56:56Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

msivasubramaniaan · 2026-02-25T21:50:36Z

How it can be used effectively:

The aggregated output is tagged by component, for example:
[backend] build started
[frontend] build started
[backend] compiling...
[frontend] bundling...
[backend] done
[frontend] done
This makes it possible to identify which component produced each log line.
Sorry - but in the current implementation there is no aggregated output is tagged by component So - it's not true: This makes it possible to identify which component produced each log line.

@msivasubramaniaan I understand that there is a technical issue and you are trying to workaround it but if you would have a choice - would you use the mixed output or separate?

my personal opinion - there are already separate terminals for each dependent task with the corresponding output - I would not use mixed output in the third terminal...

@RomanNikitenko
Here is the reference of Parallel cross component used only equal no of terminals for the list of commands.

Also the inconsistency behavior issue also fixed and removed the unnecessary logs as well

github-actions · 2026-02-26T14:24:29Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

RomanNikitenko · 2026-02-27T09:32:19Z

code/extensions/che-commands/src/compositeTaskBuilder.ts

+
+						vscode.tasks.executeTask(childTask);
+					});
+					closeEmitter.fire(0);


The most critical use case is support for Parallel Composite tasks.
In my view, the current implementation would be the best one:

it is aligned with the VS Code behavior for compound tasks

dependent tasks run in their own terminals

there is no mixed output in a single terminal (as in the previous implementation)

there are no extra terminals: number of terminals = number of dependent tasks (vs the previous approach, where it was number of dependent tasks + 1 parent terminal)

Unfortunately, the current approach has one significant drawback: if I understand correctly - actually a parent (extra) terminal is still created and then immediately closed. It looks like a bug on UI.

Screen.Recording.2026-02-27.at.11.29.26.mov

RomanNikitenko · 2026-02-27T12:18:11Z

@msivasubramaniaan
One more use case I detected is:

let's say there is a classical build and run sequential command
current behavior: the second command runs even when the first one fails
I expect: run command doesn't start - it does not make sense to run it when the previous one (build) fails
I checked that behavior for the vanilla VS Code compound task - VS Code doesn't start the second command if the first one fails

Please see on the video 2 behaviors:

the first one - for the che-code composite task
second one - for the vanilla VS Code compound task

build_and_run_bug.mov

RomanNikitenko · 2026-02-27T12:29:05Z

@msivasubramaniaan
Another problem for the sequential composite command support:

first command fails but second still runs
composite item is displayed as successful one
it's possible to detect that something went wrong only searching the corresponding logs

Update: it does not matter first command fails or the second one - command item has incorrect status...
On the screenshot bellow the second command failed

VS Code behavior, for example:

github-actions · 2026-02-27T15:43:49Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

github-actions · 2026-02-27T15:45:13Z

Pull Request images published ✨

Editor amd64: quay.io/che-incubator-pull-requests/che-code:pr-639-amd64
Editor arm64: quay.io/che-incubator-pull-requests/che-code:pr-639-arm64
Dev image: quay.io/che-incubator-pull-requests/che-code-dev:pr-639-dev-amd64

assisted-by: chatgpt-5 Added composite command support and test coverage

65b8e90

msivasubramaniaan requested review from RomanNikitenko, azatsarynnyy and vitaliy-guliy as code owners January 28, 2026 13:22

Merge branch 'main' into feat-add-composite-command-support

cb07f92

RomanNikitenko reviewed Jan 30, 2026

View reviewed changes

code/extensions/che-commands/package-lock.json Outdated Show resolved Hide resolved

resolved the license check issue

880d2ca

msivasubramaniaan requested a review from rgrunber as a code owner January 30, 2026 12:12

Merge branch 'main' into feat-add-composite-command-support

eb6c564

msivasubramaniaan requested a review from RomanNikitenko January 30, 2026 12:20

rgrunber reviewed Jan 30, 2026

View reviewed changes

RomanNikitenko reviewed Feb 2, 2026

View reviewed changes

msivasubramaniaan and others added 3 commits February 5, 2026 14:05

added label support and added execution part

4880d44

updated test cases

0eaf568

Merge branch 'main' into feat-add-composite-command-support

b91d813

msivasubramaniaan requested review from RomanNikitenko and rgrunber February 5, 2026 11:13

msivasubramaniaan marked this pull request as draft February 5, 2026 11:44

fixed the logic of execution

7572aaa

logic and test cases updated

fd06d92

logs were added

746b125

Merge branch 'main' into feat-add-composite-command-support

ba11d35

removed parent terminal logic, removed unnecessary logs

40df7c1

fixed the dropdown issue when make the problem matcher to empty

16034ff

msivasubramaniaan added 2 commits February 25, 2026 17:02

removed parent terminal completely

4ea254e

hide the parent terminal and makes only child terminal visible

73ad7de

msivasubramaniaan force-pushed the feat-add-composite-command-support branch from 22864fd to 73ad7de Compare February 25, 2026 19:45

make terminal auto close

65cf0fa

msivasubramaniaan requested a review from RomanNikitenko February 25, 2026 21:51

msivasubramaniaan added 2 commits February 26, 2026 04:19

removed unnecessary log

af36aad

removed unused variable

bada28e

RomanNikitenko reviewed Feb 27, 2026

View reviewed changes

msivasubramaniaan and others added 2 commits February 27, 2026 20:16

stop the flow if any command failed

c75351a

Merge branch 'main' into feat-add-composite-command-support

870fb61

Conversation

msivasubramaniaan commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

What issues does this PR fix?

How to test this PR?

Does this PR contain changes that override default upstream Code-OSS behavior?

Uh oh!

github-actions bot commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Jan 30, 2026

Uh oh!

rgrunber Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

RomanNikitenko Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

msivasubramaniaan Jan 31, 2026

Choose a reason for hiding this comment

Uh oh!

RomanNikitenko left a comment

Choose a reason for hiding this comment

Uh oh!

RomanNikitenko commented Feb 2, 2026

Uh oh!

RomanNikitenko commented Feb 2, 2026

Uh oh!

RomanNikitenko commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 5, 2026

Uh oh!

github-actions bot commented Feb 5, 2026

Uh oh!

github-actions bot commented Feb 5, 2026

Uh oh!

github-actions bot commented Feb 5, 2026

Uh oh!

RomanNikitenko commented Feb 24, 2026

Uh oh!

RomanNikitenko commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RomanNikitenko commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

msivasubramaniaan commented Feb 25, 2026

Uh oh!

RomanNikitenko commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 25, 2026

Uh oh!

msivasubramaniaan commented Feb 25, 2026

Uh oh!

github-actions bot commented Feb 26, 2026

Uh oh!

RomanNikitenko Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

RomanNikitenko commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RomanNikitenko commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Feb 27, 2026

msivasubramaniaan commented Jan 28, 2026 •

edited

Loading

github-actions bot commented Jan 28, 2026 •

edited

Loading

RomanNikitenko commented Feb 5, 2026 •

edited

Loading

RomanNikitenko commented Feb 24, 2026 •

edited

Loading

RomanNikitenko commented Feb 24, 2026 •

edited

Loading

RomanNikitenko commented Feb 25, 2026 •

edited

Loading

RomanNikitenko commented Feb 27, 2026 •

edited

Loading

RomanNikitenko commented Feb 27, 2026 •

edited

Loading