Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
APINYK opened this issue Jun 24, 2024 · 5 comments
Assignees
Labels
kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system. sprint/next status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach

Comments

@APINYK
Copy link

APINYK commented Jun 24, 2024

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.

DS13_to_DS14_bug.mp4

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

@APINYK APINYK added the kind/bug Outline of a bug - must adhere to the bug report template. label Jun 24, 2024
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Jun 24, 2024
@ibuziuk ibuziuk added status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach severity/P1 Has a major impact to usage or development of the system. and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Jun 24, 2024
@AObuchow
Copy link

AObuchow commented Jul 2, 2024

After testing the reproducer, I noticed the following:

  • The devfile does not have any projects
    • But the devworkspace does have a project. I assume the dashboard is injecting it.
  • When restarting from local devfile, the projects in the devworkspace are lost (probably since they didn't exist in the devfile from the start):
  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
Copy link
Contributor

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
Copy link

AObuchow commented Jul 3, 2024

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
Copy link
Contributor

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
Copy link
Author

APINYK commented Jul 8, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Outline of a bug - must adhere to the bug report template. severity/P1 Has a major impact to usage or development of the system. sprint/next status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach
Projects
Status: ✅ Done
Development

No branches or pull requests

5 participants