[Minor Proposal] Add ability to change current theia workspace folder with help devfile.

[AndrienkoAleksandr]

Description

On start che-theia we start che-theia with hard-coded theia workspace folder "/projects". Potentially we could implement ability to change theia workspace folder with help devfile. It's could be useful for go-lang workspaces.

[skabashnyuk]

@AndrienkoAleksandr #13006 is this something that can help you?

[AndrienkoAleksandr]

No, I meant workspace theia path, not git subfolder path on project clone.

[sunix]

@AndrienkoAleksandr could you detail a complete workflow ? with a concrete example ?

[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.

[tolusha]

I've reopened the issue since I've faced a real case when we need it.
Go language server requires the project to be the root of the workspace otherwise it can't find some imports.

eclipse-che/che-devfile-registry#96

[azatsarynnyy]

I'm +1. Another case is the Kubernetes Tooling Che plugin. It also requires a project folder to be opened as a Theia Workspace root folder for executing some commands.

[tsmaeder]

@tolusha I thought golang requires us to check out projects in a fixed location depending on the package name. Do you know how it would work in a setup with multiple workspace roots?

[tolusha]

@tsmaeder Since 1.11 there is ability to put go project in a arbitrary folder.

[1] https://blog.golang.org/using-go-modules

[tsmaeder]

@tolusha yes, but what do we need to pass to the language server to make it work? I thought we were multi-root safe for all languages. Could you confirm?

[tsmaeder]

@tolusha ping?

[tolusha]

From my understanding arbitrary folder will be set as workspace root and will be passed to LS.

[tsmaeder]

Depends on multi-root workspaces, AFAIC.

[sunix]

closing as duplicate of #15347 (which contains a implementation proposal)