path of project is not taken in account when cloning projects of a workspace

[sunix]

Description

Projects defined in a classic workspace configuration in Che6 were able to handle path which was the folder related to /projects where a project would be located

for instance

    {
      "name": "che-theia",
      "source": {
        "location": "https://github.com/eclipse/che-theia.git",
        "type": "git"
      },
      "path": "/subfolder/che-theia"
    },

Would have the project che-theia being clone into /projects/subfolder/che-theia.
It seems it is not possible to defined project in another location than underneath /projects

I have not tried with clonePath of a devfile but I suspect we have the same issue.

[sunix]

@nickboldt, @l0rd, @slemeur, @tsmaeder and @rhopp ? for GA ?

[slemeur]

This does look like a capability that we have not implemented back in Che 7.

I would label it as an enhancement, as this is not really creating a bug to the user. He would still be able to get his project imported but will miss the ability to specify a subfolder.

[slemeur]

Unless we are documenting the use of the path and it was implemented, switching this to "kind/enhancement"

[sunix]

yes we had that in che7 but i think this is working for "devfile typed" workspaces.
But there is a difference between devfile and workspaceconfig: workspace config is taking / in the path.

    {
      "name": "che-theia",
      "source": {
        "location": "https://github.com/eclipse/che-theia.git",
        "type": "git"
      },
      "path": "/subfolder/che-theia"
    },

but devfile doesn't

  - name: che-theia
    clonePath: subfolder/che-theia
    source:
      type: git
      location: 'https://github.com/eclipse/che-theia.git'

But implementation is the same from my understanding, everything has been refactored eclipse-che/che-theia#242 ... so unless you start a workspace from a devfile with the factory or the sample, everything is broken (workspace sync ... etc ...)

But if we fix #13623
And if we say that in che7 we shouldn't have anyway to create a workspace config workspace. Then i would say it is fine not to fix it.

[tsmaeder]

Go requires a particular folder structure. Is this related to that problem?

[sunix]

I have just made some tests.
I think we can skip that one if we concider that we don't support anymore the old workspace structure (not based on devfile) but then, that one #13623 becomes really blocker because creating a workspace from a devfile will create a workspace with the old structure.

From what i have tested, everything related to cloning and project sync is broken when you are using the legacy workspace structure. If you manage to start a devfile workspace, things are better but we still have this sync issue #13621.

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