Epic: Start Fresh Projects

[svenefftinge]

New projects are usually started in a dev environment. Therefore we want to allow starting workspaces that are not connected to a remote git repository. they might be completely empty or seeded based on an archive.

• Open workspace with files from a template context but no git remote #6903
• Epic(experiment): Allow creating a new repository from within the IDE #6904
• Epic(experiment): Create new projects and enable prebuilds from within the IDE #6906

[loujaybee]

I really like the idea of letting a user configure a repo from a blank canvas (not associated to a repo).

Question for those reading: Would the intention be to nudge a user towards always creating a project configuration? Would weakening the (currently strong) connection of a workspace with a repo as a 1<>1 have any impacts on users perception of how Gitpod is to be used (to codify setup of a project / repo? Or are we open to experimenting with that?

I have a generic blank project that I use as my personal "start point" when I don't have (or want) a repo to start from.

[ntziolis]

Creating a new repo from an existing template repo would be a great start. Some further thoughts:

• New projects are often created using CLI generators (angular, nx, ionic etc.)
• Hence it would be great if a custom script could be executed ONCE at project creation
• However these CLI commands require variable inputs (project name etc.)
• These variables should be
  • collected prior to the setup script being executed
  • and the values should be available for the script to use

Based on the above I propose

• creating "gitpod-templates"
• and a corresponding gallery that also allows marking templates as public for others to use
• when choosing a template with variables from the gallery a UI would be rendered to collect variable values and make them available as environment variables of the downstream project creation process.

A simple template structure could be something like:

• name / description (to be displayed in library)
• variables
  • name
  • type
    • initially could be text only
    • but later should allow more precise control like
      • providing a type
      • providing a set of valid values (think dropdown)
• type specific properties
  • for clone type it would be the clone url
  • for script it would be the script

A template approach has the following advantages:

• Enables CLI based project creation
• Through use of a generator CLI enable templates that are always up to date during time of creation
  • This is a major issue when looking at how fast certain ecosystems move (angular etc.)
• Enables sharing of complex up to date templates easily
  • One of my major beefs with stackblitz shared repos is that thy are almost always out of date

[jwpjrdev]

I wouldn't mind working on this a little. Are there any mockups for what such a menu would look like 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.

[jwpjrdev]

can someone make this never-stale?