Allow specifying a .code-workspace file via Devfile

[KevinMGranger]

Is your enhancement related to a problem? Please describe

Our project repos contain a .devfile.yaml, and sometimes a $SOMETHING.code-workspace file. If using a devfile that clones multiple projects, then the code-workspace file is necessary to open them all in the same window.

It's annoying to tell users to open that file and manually click "open workspace". It also takes additional time to reload the editor.

Describe the solution you'd like

Allow specifying a code-workspace file to open by default via an attribute in the devfile.

Describe alternatives you've considered

• Allow specifying the workspace file through the workspace creation URL
  • you can already use ?workspace=$SOMETHING.code-workspace in the workspace URL, but not at creation time
  • this still is additional manual work for a user.
• Default to creating a new code-workspace when multiple projects are specified in the devfile
  • This is actually a pretty nice UX
  • If we want to use suggested extensions and per-workspace settings, that's additional work just to recreate what the code-workspace file already does

Additional context

A minimalist example of how it might work:

.devfile.yaml:

schemaVersion: 2.2.0
components:
  - name: name
    container:
      mountSources: true
      attributes:
        che-code.eclipse.org/workspace-file: mono/something.code-workspace
      # other parts elided
# other parts elided
projects:
- name: monorepo-kinda-setup
  clonePath: mono
  git: {remotes: {origin: https://example.com/monorepo.git}}
- name: repo1
  git: {remotes: {origin: https://example.com/repo1.git}}
- name: repo2
  git: {remotes: {origin: https://example.com/repo2.git}}

something.code-workspace:

{
  "folders": [
    { "path": "." },
    { "path": "../repo1" },
    { "path": "../repo2" }
  ]
}

[l0rd]

Setting P1 as this has been raised multiple times in the last weeks. Until recently we didn't invest in multi-project devfiles as we wanted to deprecate them. But the recent numerous feedback asking to keep multi project support led us to the decision to support them (although in a slightly different way).

That said I am not sure if specifying a VS Code workspace file is the right approach:

• as a the developer I will expect to see my projects in VS Code whether or not there is VS Code workspace file
• it's a VS Code specific solution

Other alternatives when there are more than one project:

• use ${PROJECTS_ROOT} rather than ${PROJECT_SOURCE} as the value for VS Code --default-folder parameter
• generate a VS Code workspace file before starting the IDE and then use --default-workspace parameter rather than --default-folder

@azatsarynnyy what do you think? I believe you worked on something similar for Theia at the time.
@KevinMGranger I am changing the title to reflect the problem rather than the solution. I hope that's ok for you.

[KevinMGranger]

• Title change: totally fine! It's partially an XY problem, of course :)
• Defaulting to PROJECTS_ROOT might be okay, but I'd have to think about / experiment with with UX of that.
  • For example, for multi-root workspaces (these terms are so overloaded :) ), Code will open new terminals in the the folder of the currently open file. If the --default-folder is set to a parent directory, I don't think that will happen. But I'm unfamiliar with that flag.
• Generating a workspace file could totally work!

Those solve the problem of viewing all projects by default. However, I think there's still value in specifying an existing workspace file. Since it's an annotation, we wouldn't expect it to work if you're not using Code. Perhaps that's a separate issue to solve?

[cgruver]

++1 on this request.

Here's an example project with multiple repos:

https://github.com/eclipse-che-demo-app/che-demo-app.git

[azatsarynnyy]

I'd add a bit of history of the topic to the context )
We used to have a good logic that detected the right folder(s) to open. The problem was that the folders list were opened by vscode.openFolder command which led to reloading the page. It wasn't a good UX and we decided to get rid of it.
At that time, we thought that there will be no multi-project workspaces support. So, 100% of the workspaces are supposed to contain a single project. That's why it was reworked to always open ${PROJECT_SOURCE}.

Considering the latest update:

Until recently we didn't invest in multi-project devfiles as we wanted to deprecate them. But the recent numerous feedback asking to keep multi project support led us to the decision to support them (although in a devfile/api#1082).

now, it's time to reconsider again the approach of opening the project(s) sources in Che Code 🙂

use ${PROJECTS_ROOT} rather than ${PROJECT_SOURCE} as the value for VS Code --default-folder parameter

Despite the fact that it looks like a simplest and right solution, it brings a lot of problems. I remember experimenting with that and it turned out that it breaks even some basic UXes. For example:

• VS Code didn't see projects config files, like tasks.json, settings.json, launch.json, etc.
• some extensions stoped to work, like Java extension as Code Workspace Folder was /projects
• and many more problems appeared

So, I wouldn't use ${PROJECTS_ROOT} for that.

generate a VS Code workspace file before starting the IDE and then use --default-workspace parameter rather than --default-folder

I agree that it would be the best solution. Actually, we need to reimplement the logic, we used to have in the TS extension, to have it in Che-Code entrypoint.

[cgruver]

We also need to ensure that we cover the use case where a .code-workspace file already exists in the same repo as the devfile. A team that creates one ahead of time ensures an opinionated starting point for others on the same product team.

[hecsoriano]

Just our 2 cents here. Most of our workspaces are multi root projects so the mono repo approach caused some challenges to our dev workflow. We ended up running a patched devworkspace operator that sets PROJECT_SOURCE pointing to /projects.

Out of convenience we usually have a bootstrap event that clones additional repos and sets workspace settings, tasks and plugins (this may be the reason we are not facing the issues @azatsarynnyy mentions above)

This works fine for us (no problems with vscode plugins and developers have a great UX) but we'd love to see multi-root projects natively supported 👍

[l0rd]

I have created a PR to support loading a vscode workspace file at startup through an env variable:

schemaVersion: 2.2.0
(...)
components:
- name: dev-tools
  container:
    (...)
    env:
    - name: VSCODE_DEFAULT_WORKSPACE
      value: "/projects/che-demo-app/che-demo.code-workspace"

The environment variable should be set in the container that hosts VS Code (the first component or the component with attribute controller.devfile.io/merge-contribution: true).

As an example I have used @cgruver repo and added the env variable.

For Che 7.64 or higher and Dev Spaces 3.6 or higher I have a gist with a VS Code spec (uses image quay.io/mloriedo/che-code:insiders) and that can be tested using a URL like:

<che-host>/#<repo-url>?che-editor=https://gist.githubusercontent.com/l0rd/d970c5ac4fc66aa3b7162360d3efee85/raw/che-code.yaml

[cgruver]

@l0rd This works great!

I set checluster.spec.devEnvironments.defaultEditor: https://gist.githubusercontent.com/l0rd/d970c5ac4fc66aa3b7162360d3efee85/raw/che-code.yaml, and It works perfectly.

[cgruver]

@l0rd @KevinMGranger It looks like this feature made it into v7.68

I think we can close this now.

[KevinMGranger]

🎉🎉🎉

[l0rd]

I have renamed this issue with it's original title and opened another issue for the case when the workspace file doesn't exist: #22280