Create new project by cloning a template

[svenefftinge]

The new project flow, should allow users to pick a template and create a fresh project based on that.

As a result, a user should be able to create a fresh repository with the initial scaffolding provided by the picked template. The repo should be added to the githoster the user chose and live under the org/group the user had chosen during the project creation flow.

As with imported projects the user get directed to the configuration page, which should already run a prebuild if the .gitpod.yml exists.

To be investigated:

• create projects only based on existing git repos, or can we support running other project creation tools (spring boot, react starter, etc.) with reasonable complexity and effort?

[JohannesLandgraf]

FWIW, with the /quickstart section in docs we (in words) followed a similar flow: https://www.gitpod.io/docs/quickstart/ruby-on-rails. Really looking forward to get this written in code and productized

[JanKoehnlein]

Are there any insights on the effort yet? Given the time until the official launch we should maybe postpone that and remove it from "needed for shipping"

[gtsiolis]

Thanks @JanKoehnlein! Moving this to the Next Iteration for now unless we manage put some effort on this for next week.

[svenefftinge]

Now, that new users land in the /new flow, we should allow them to pick a template to start fresh projects rather than only importing existing projects. I think it could be cool to design this feature, so that I can use a context URL with an archive or so, that is used. So people can build links to easily start projects based on their own templates.

[svenefftinge]

@jldec @JanKoehnlein happy to jump on a call to explore this in more depth.

[jldec]

MVP design ideas

cc: @gtsiolis

How about reusing the list of docs quickstart template repos from the website?

1. Render the quickstart templates in a single-page view with names, icons?, short descriptions? (something nicer than a dropdown, no need for pagination but a simple in-page search would be nice)

2. Use the github template generate feature to create the repo inside the GitHub UI (instead of via API) e.g. https://github.com/gitpod-io/template-golang-cli/generate This provides users with control over the repo name, and avoids silent auth issues. It also avoids cloning the git history unless users ask for it.

3. Somehow bring the repo name/url back into the Gitpod new project flow - not sure how to do this without a form-like input, but even that would not be the worst thing to do IMO.

[jldec]

/schedule

[roboquat]

@jldec: Issue scheduled in the meta team (WIP: 0)

In response to this:

/schedule

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[svenefftinge]

Use the github template generate feature to create the repo inside the GitHub UI (instead of via API) e.g. https://github.com/gitpod-io/template-golang-cli/generate This provides users with control over the repo name, and avoids silent auth issues. It also avoids cloning the git history unless users ask for it.

It would be nice to reuse something indeed, but this would

1. not work for GitLab users
2. kick users out of the project creation flow

Instead, we should have a single page where users can pick the org, name and whether the repo should be public/private. And then generate and initialize the project for them based on an archive.

[jldec]

See also #6645

[jankeromnes]

FYI, I'd be interested in working on this, if nobody else wants to 😊 (and I'd wait for the required visual designs, but I'm also happy to discuss / help create these designs)

[jldec]

/assign @jankeromnes

Thanks Jan, let's start with a really minimal design as suggested by @svenefftinge

It would be great to have the mechanics of new repo creation with error handling working so that we can better understand the necessary user interactions, while we work on the UI design in parallel.

• the input template source comes from a selection earlier in the flow
• the org/name of the new repo is derived/proposed based on the input but can be overriden by the user
• the new repo defaults to public but that can also be overridden by the user

[jankeromnes]

Thanks @jldec, good idea!

One small note: I believe that there are at least two ways to create a repo based on a template:

1. Use the GitHub template feature ("Use this template" button going to /generate URL, e.g. https://github.com/gitpod-io/template-sveltejs/generate )
2. Do something more "manual" and generic based on an archive (e.g. https://github.com/gitpod-io/template-sveltejs/archive/refs/heads/master.zip )

My current understanding is that we'll likely skip 1. for now (GitHub-only and more restrictive) and implement 2. (but try to follow established standards with respect to project name, commit author, commit message, etc)

[jldec]

Yes - good point - I had similar intuitions, but after playing with the Vercel UI (see below) I think the "create repo" UX can be quite small & simple. See also comments above.

[jankeromnes]

Following yesterday's discussion (internal), we've decided to discontinue work on this issue (i.e. choosing a template during Project creation) for now, and instead focus on #6903 (opening archives in Gitpod); #6904 (allowing repository creation from the IDE); and #6906 (allowing Project creation from the IDE).

[jankeromnes]

In case this is helpful in the future, here is my work-in-progress branch implementing a "create a repository from a template repository" feature:

#6850

https://github.com/gitpod-io/gitpod/compare/jx/project-templates

6b081dd

It's able to successfully create new repositories from a GitHub or GitLab template, and has a minimal UI in the dashboard:

[stale]

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.

[JanKoehnlein]

I think we have chosen a different path with the new open workspace dialog and the auto-inference of the .gitpod.yml. Re-open if you disagree