eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams
http://eclipse.org/che
Eclipse Public License 2.0
6.94k stars 1.18k forks source link

After upgrading from Dev Spaces 3.13 to 3.14 - Single root workspace not working as expected #23014

Closed APINYK closed 1 week ago

APINYK commented 1 month ago

Describe the bug

Hi guys!

After upgrading from Dev Spaces 3.13 to 3.14 the single root workspace does not work properly anymore.

After starting a workspace from Github everything seems to be working fine. However when "Restarting from local devfile" the project folder is lost.

Che version

7.87@latest

Steps to reproduce

  1. Go to https://devspaces.apps.sandbox-m3.1530.p1.openshiftapps.com/dashboard/#/create-workspace
  2. Create workspace from branch: https://github.com/Nykredit/openshift-test/tree/single_root
  3. After startup you should have the following:
  4. image
  5. Press: Cntl+Shift+P to open the command palette and choose "Restart Workspace from Local Devfile"
  6. image
  7. Choose:
  8. image
  9. After restart the project root has changed to look like this:
  10. image
  11. And settings will not kick in anymore.

Please watch attached video to see the above behavior.

https://github.com/eclipse-che/che/assets/127222595/2c7e8a29-7c99-40f7-ab39-7a6e041964ff

Expected behavior

After restart the single root setup should not change.

Runtime

OpenShift

Screenshots

No response

Installation method

OperatorHub

Environment

Dev Sandbox (workspaces.openshift.com)

Eclipse Che Logs

No response

Additional context

No response

AObuchow commented 3 weeks ago

After testing the reproducer, I noticed the following:

  template:
    attributes:
      controller.devfile.io/devworkspace-config:
        name: devworkspace-config
        namespace: crw
      controller.devfile.io/scc: container-build
      controller.devfile.io/storage-type: common
    components:
      - attributes:
          controller.devfile.io/merge-contribution: true
        container:
          env:
            - name: VSCODE_DEFAULT_WORKSPACE
              value: /
          image: registry.redhat.io/devspaces/udi-rhel8
          sourceMapping: /projects
        name: python
-    projects:
-      - git:
-          checkoutFrom:
-            revision: single_root
-          remotes:
-            origin: 'https://github.com/Nykredit/openshift-test.git'
-        name: openshift-test

As a temporary workaround, a project could be added to the reproducer devfile and that should resolve the issue.

I believe the fix for this issue probably requires the devworkspace generator tool to do a strategic merge of the local devfile and the existing devworkspace: only fields that are modified in the devfile should be modified in the devworkspace, rather than replace the entire devworkspace's spec.template with the local devfiles content. This approach is being used in DWO for bootstrapping a devworkspace from a cloned devfile, and could be followed.

vitaliy-guliy commented 3 weeks ago

Let's start from the beginning to understand the cause of the problem. It can be easily reproducible by everyone.

Before workspace restart, open the terminal and check for PROJECTS_ROOT and PROJECT_SOURCE environment variables. For the provided sample it looks like this

declare -x PROJECTS_ROOT="/projects"
declare -x PROJECT_SOURCE="/projects/openshift-test"

After restarting from local devfile, the PROJECT_SOURCE has been truncated to /projects/openshift-test

declare -x PROJECTS_ROOT="/projects"
declare -x PROJECT_SOURCE="/projects"

Why does it happen was described in the comment above.

It needs some time to decide what should we do here. Whether we add the project to the devfile right before the workspace restart. Or whether we give the user freedom, do not change anything under the hood and make the launcher responsible for opening in single-root mode if the PROJECT_SOURCE is truncated to /projects.

AObuchow commented 3 weeks ago

It needs some time to decide what should we do here. Whether we add the project to the devfile right before the workspace restart. Or whether we give the user freedom, do not change anything under the hood and make the launcher responsible for opening in single-root mode if the PROJECT_SOURCE is truncated to /projects.

My opinion is still that the devworkspace generator tool that is being used to modify the devworkspace object with the local devfile needs to be improved to more carefully merge the local devfile and devworkspace, similar to how DWO does it.

There are probably other cases where the Che Dashboard is modifying the DevWorkspace resulting from a DevWorkspace: in other words, we can't assume there's a 1 to 1 correspondance between the local Devfile and the DevWorkspace. In the future, there might be other bugs that arise from these differences between the local Devfile and DevWorkspace. Merging the devfile and devworkspace strategically would hopefully prevent these future bugs from occuring.

vitaliy-guliy commented 3 weeks ago

As a workaround it is possible to add the current project to the devfile. For the repository described in the issuse description is may look like this

schemaVersion: 2.1.0
metadata:
  name: folder_based
projects:
  - name: openshift-test
    git:
      remotes:
        origin: https://github.com/Nykredit/openshift-test.git
      checkoutFrom:
        revision: single_root
components:
  - name: tools
    container:
      image: registry.redhat.io/devspaces/udi-rhel8
      env:
        - name: VSCODE_DEFAULT_WORKSPACE
          value: "/"
APINYK commented 2 weeks ago

Thanks for you prompt responses and the workaround. For now we will move on with the workaround.