How can I find tasks.json since it's no longer under /projects folder?

[SDAdham]

Summary

I have updated the devfile to use latest version from theia, today I am creating a new workspace, and the directory .theia in the project folder is no longer used and not created, I created it and yet it's still not used.

Because I am using promptString and shell tasks, I don't know how to write these in the devfile, so what I do, is that I created a tasks that overwrites the tasks.json. Can you please advise a workaround or share examples of devfiles with shell tasks and input are used?

Relevant information

Version: Che-Theia@9d3a00a using Theia@c837b6cb

[l0rd]

the consequences of multi-root workspaces? cc @azatsarynnyy @ericwill

[azatsarynnyy]

After eclipse-che/che-theia#739, imported Che Commands are stored on the user level, in /home/theia/.theia/tasks.json.

[RomanNikitenko]

it makes sense to provide some changes to the doc https://www.eclipse.org/che/docs/che-7/defining-custom-commands-for-che-theia/ to inform user that che tasks configurations from the devfile are exported to user level tasks.json file (instead of /workspace/.theia directory)

[ericwill]

it makes sense to provide some changes to the doc https://www.eclipse.org/che/docs/che-7/defining-custom-commands-for-che-theia/ to inform user that che tasks configurations from the devfile are exported to user level tasks.json file (instead of /workspace/.theia directory)

@tsmaeder can you take care of this?

[l0rd]

Communication on mailing lists(internal/external) would help as well

[tsmaeder]

We're still using the same single-root workspace we used to. @SDAdham could you give a concrete example of what you're trying to do? Using shell tasks in /projects/.theia/tasks.json should still work at this time.

[tsmaeder]

I've just put this into /projects/.theia/tasks.json and it works fine with che-theia:next:

{
    "tasks": [
        {
            "type": "shell",
            "label": "a shell task",
            "command": "sleep 5 && echo ${input:input1}"
        }
    ],
    "inputs": [
{
    "id": "input1",
    "type": "promptString",
    "description": "the first input"
}

    ]
}

[SDAdham]

Hello @tsmaeder ,

It doesn't work with che 7.15.0, I tried defining task in devfile,

My issue with tasks, I am trying to get variables like: ${server.node-web} and ${server.java-web}

These varables don't work with che runner, but it works as a shell:

        {
            "type": "shell",
            "label": "Export environment variables",
            "command": "sleep 2 && export FRONTEND=\"${server.node-web}\" && export BACKEND=\"${server.java-web}\" && bash dir/someScript.sh"
        },

Now the shell above can't be written in devfile, for some reason, it won't work or won't show up even in the task list from both right pane and terminal menu, example:

  - name: Export environment variables
    actions:
      - referenceContent: |
          {
            "version": "2.0.0",
            "configurations": [
              {
                "type": "shell",
                "label": "Export environment variables",
                "command": "sleep 2 && export FRONTEND=\"${server.node-web}\" && export BACKEND=\"${server.java-web}\" && bash proj/someScript.sh"
              }
            ]
          }
        type: vscode-task

So as a workaround, I created an additional task:

  - name: Prepare che tasks
    actions:
      - workdir: '${CHE_PROJECTS_ROOT}/proj'
        type: exec
        command: sleep 2 && cp ./.che/tasks.json ../.theia/tasks.json
        component: node-server

Now considering that .theia directory in /projects doesn't exist and won't work. I have to manually copy tasks.json to /home/theia/.theia/tasks.json and then all other tasks will work.

Can you please provide a devfile with commands that solves the puzzles above? I'd really appreciate it. For example, if I can give up the Prepare che tasks completely. That'll be really great.

Thanks,
Adham

[tsmaeder]

I was able to confirm that the replication of the vscode-task action to user level tasks does not work in che-theia:next.
@SDAdham where do the "server.node-web" and "server.java-web" variables come from?

[tsmaeder]

In the theia log, I can seen the following lines:

2020-07-09 08:04:55.912 root ERROR [hosted-plugin: 50] Error parsing configurations: error: 4, length:  0, offset:  0 
2020-07-09 08:04:55.918 root ERROR [hosted-plugin: 50] Error parsing configurations: error: 4, length:  0, offset:  0 

This indicates the the tasks plugin cannot parse some task definition from the devfile.

[tsmaeder]

In the end, the mystery is not that deep:

            "configurations": [

should read

            "tasks": [

@SDAdham does that fix your problem? I agree writing a message to a log the user never sees is not the best way to help the user 🤷

[SDAdham]

@tsmaeder "server.node-web" and "server.java-web" these are the alias of the webservers defined in the devfile, those are needed because the URL changes every time you spin up a new workspace.

I'll try changing configurations to tasks and will let you know.

[SDAdham]

@tsmaeder : I made those changes to 2 tasks, both didn't appear in the right pane but only one of them appeared from Terminal menu at the top and worked

[SDAdham]

I grouped the 2 tasks together in the reference and both showed up from the Terminal menu at the top but still no left pane

[SDAdham]

I tried adding target -> component thinking that it might be due to those 2 missing, but still no difference.

[tsmaeder]

@SDAdham both things you describe are working as expected:

both didn't appear in the right pane

Only commands of type "che" from the devfile appear in the "my workspace" bar

I grouped the 2 tasks together in the reference and both showed up

You can only have one command of type "vscode-task" per workspace. Looking at the code, that is explicitly the intention.

So as far as this issue is concerned, I think it "works as designed". If you have enhancement requests, I would propose that you open an issue. It's easier to discuss concrete improvements that way.

[che-bot]

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.