Skip to content

Is it possible to have clonePath clone to nested directories under /project? #7290

Open
@isuftin

Description

/kind feature

Which functionality do you think we should add?

I have a devfile where I am checking out five projects, Projects A and B are related (For example they're both Docker type projects) while the other three are related in that they're documentation type projects.

Example:

projects:
  - name: docker-project-1
    clonePath: "docker-project-1"
    git:
      remotes:
        origin: "https://my-git.server/docker-project-1.git"
      checkoutFrom:
        revision: development
  - name: docker-project-2
    clonePath: "docker-project-2"
    git:
      remotes:
        origin: "https://my-git.server/docker-project-2.git"
      checkoutFrom:
        revision: development
  - name: docs-project-1
    clonePath: "docs-project-1"
    git:
      remotes:
        origin: "https://my-git.server/docs-project-1.git"
      checkoutFrom:
        revision: development
  - name: docs-project-2
    clonePath: "docs-project-2"
    git:
      remotes:
        origin: "https://my-git.server/docs-project-2.git"
      checkoutFrom:
        revision: development
  - name: docs-project-3
    clonePath: "docs-project-3"
    git:
      remotes:
        origin: "https://my-git.server/docs-project-3.git"
      checkoutFrom:
        revision: development

I have a .code-workspace file in the same project. In that file I have a folders object. The folders object has each of the five projects

{
	"folders": [
		{
			"name": "docker/docker-project-1",
			"path": "/projects/docker-project-1"
		},
		{
			"name": "docker/docker-project-2",
			"path": "/projects/docker-project-2"
		},
		{
			"name": "documentation/docs-project-1",
			"path": "/projects/docs-project-1"
		},
		{
			"name": "documentation/docs-project-2",
			"path": "/projects/docs-project-2"
		},
		{
			"name": "documentation/docs-project-3",
			"path": "/projects/docs-project-3"
		},
	]
}

The issue with this is that in the workspace, the projects are not grouped by name so I can't collapse all of the docker projects or all of the documentation projects. And ideally I'd also like to have the projects checked out follow the same project path as they show up on the git server, so this would be long paths (group-name/project-type/maybe-something-here/project-name).

Ideally if I were able to, in the devfile, set the clonePath to /projects/arbitrary/nested/dir/docker-project-1, /projects/arbitrary/nested/dir/docker-project-2, etc, this would work out great.

But currently I can't seem to check out to anywhere but directly into /projects/

What ends up happening looks like:

2025/02/25 19:11:09 Processing project starter-workspace
2025/02/25 19:11:09 Cloning project starter-workspace to /projects/project-clone-3989625933/projects/subdir/starter-workspace
Cloning into '/projects/project-clone-3989625933/projects/subdir/starter-workspace'...
2025/02/25 19:11:10 Cloned project starter-workspace to /projects/project-clone-3989625933/projects/subdir/starter-workspace
2025/02/25 19:11:10 Setting up remotes for project starter-workspace
2025/02/25 19:11:10 Fetched remote origin at https://my-git.server/dev-files/starter-workspace.git
2025/02/25 19:11:10 Checking out remote branch development
Switched to a new branch 'development'
branch 'development' set up to track 'origin/development'.
2025/02/25 19:11:10 Moving cloned project starter-workspace from temporary directory /projects/project-clone-3989625933/projects/subdir/starter-workspace to /projects/subdir/starter-workspace
2025/02/25 19:11:10 Encountered error while setting up project starter-workspace: failed to move cloned project to /projects: rename /projects/project-clone-3989625933/projects/subdir/starter-workspace /projects/subdir/starter-workspace: no such file or directory

Why is this needed?

This would make for far easier organization of related projects in a multi-root workspace

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue as a feature request. For PRs, that means that the PR is the implementationneeds-triageIndicates an issue or PR lacks a `triage/*` and requires one.

    Type

    No type

    Projects

    • Status

      No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions