Skip to content

New Gitpod from sub directory of a (mono) repo #6645

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

Open
schickling opened this issue Nov 10, 2021 · 6 comments
Open

New Gitpod from sub directory of a (mono) repo #6645

schickling opened this issue Nov 10, 2021 · 6 comments
Labels
feature: multi-repo meta: never-stale This issue can never become stale team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team

Comments

@schickling
Copy link

schickling commented Nov 10, 2021

Similar to how GitHub has the template repository feature I'd like Gitpod to support a similar workflow by being able to create a new Gitpod from a sub directory of a (mono) repo.

This workflow is already possible "locally" with the following terminal command:

curl https://codeload.github.com/contentlayerdev/contentlayer/tar.gz/main | \
  tar -xz --strip=2 contentlayer-main/examples/mdx

Use case

Many projects (such as https://github.com/vercel/next.js and https://github.com/vercel/next.js) keep both their source code as well as example projects in the same repo. In order to try out an example (or investigate a bug report or create a bug repro) I often want to start of with a new Gitpod project that only consists of a given example folder (e.g. this one).

There would be a few downsides of cloning the entire project repo:

  • Cloning takes much longer than downloading the tar.gz
  • Installing the project dependencies (e.g. via yarn) should only install the dependencies needed for the single example - not all other dependencies of the (mono) repo.

Bonus feature: Allow me to create a new GH repo from the project I'm working on (e.g. to report a bug using the created reproduction).

Thoughts on "API design"

It would be great if Gitpod could simply extend the URL-based create flow (i.e. gitpod.io/#github.com/owner/repo) to also allow for "copy & paste"-able sub dir URLs (e.g. https://github.com/contentlayerdev/contentlayer/tree/main/examples/mdx)

@corneliusludmann
Copy link
Contributor

Just a tiny note: Using a URL like https://github.com/contentlayerdev/contentlayer/tree/main/examples/mdx as context URL is supported already:

https://gitpod.io/#https://github.com/contentlayerdev/contentlayer/tree/main/examples/mdx

However, it just opens the file in the editor or the folder (in this case) in the tree view. It does not change the root folder for OpenVSX. But you can run $ open examples/mdx/ in the terminal (or use FileOpen Folder...) for this.

It would be worth thinking about it if we should change the behavior here, IMHO.

But even when we open the given folder in OpenVSX (and probably use the .gitpod.yml file in this subfolder so that you don't need to install all the dependencies for the mono repo) you still need to clone the whole repo.

@stale
Copy link

stale bot commented Feb 10, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Feb 10, 2022
@schickling
Copy link
Author

👋 @Stale

@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label Feb 10, 2022
@sagor999 sagor999 added the team: workspace Issue belongs to the Workspace team label Feb 25, 2022
@stale
Copy link

stale bot commented May 30, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label May 30, 2022
@schickling
Copy link
Author

Still relevant

@gtsiolis gtsiolis added the meta: never-stale This issue can never become stale label May 31, 2022
@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label May 31, 2022
@jldec jldec added the team: webapp Issue belongs to the WebApp team label May 31, 2022
@jldec
Copy link
Contributor

jldec commented May 31, 2022

Adding WebApp since this is related to multi-repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature: multi-repo meta: never-stale This issue can never become stale team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team
Projects
Status: No status
Development

No branches or pull requests

6 participants