Templating: Add git provider as a source for templates

[sayedihashimi]

Currently for sources we have Folder and Zip style packages. We should investigate what it would take to add git as a provider. I think this will make creating and sharing templates for the community drop dead simple. Let's discuss more soon.

[motowilliams]

I'm curious to what the assumptions and thoughts for this feature might be

• [ ] a repo with a pre-defined / well known structure
• [ ] git in the users path
• [ ] supports both public and private repos
• [ ] supporting hosted repos other than just GitHub
• [ ] will there be additional switches that enable getting a template from arbitrary commits? Branches, Tags, Hash
• [ ] how is the version filter going to work or is this even apporpiate for the git provider
• [ ] how does the update scenario work? User installs a template and then template updates are later committed and pushed
• [ ] both ssh and http supported for this feature
• [ ] how about a validation switch to test that repo is setup correctly so that we can avoid clippy feedback about a 'looks like you're trying to clone a git template'

[sayedihashimi]

@motowilliams thanks for the comments. We have just started thinking about this, we don't have very specific plans but I can let you know what I'm currently thinking. These are all just my initial thoughts, if you have any concerns or ideas please chime in as none of this is set in stone.

a repo with a pre-defined / well known structure

For the first release I'm thinking that the git repository should contain 1 or more .template.conig\template.json files. When a user invokes dotnet new --install <giturl> the repository will be cloned locally and then the Template Engine will discover templates in a similar fashion to when a folder path is added (i.e. it will discover and add all templates from the .template.config\template.json files. Later on we can think about the case that a repository contains a single project/solution and we want to create a project from that without any metadata files. I'm not sure if that's really useful or not because a user could just clone that. I think we'll need some replacements to make it a useful template.

After the repository is cloned we should have a command like dotnet new --update <identifier> where the identifier is the git url or the template name. I'm not sure what's the right approach there yet. The idea here is that we would get latest on the repository and then re-register the templates from that folder. (Note: this essentially requires us to be able to uninstall templates which we don't have yet).

git in the users path

I think there are 2 high level ways we can add support for git.

• Use a library like libgit2sharp to make calls to git directly
• Assume that git is on the path and use that

There are pros/cons to both approaches here. The advantage of using git on the path is that we would be able to leverage auth flows like ssh/https easily if they have already been configured. Without this I think we'll need to spend a lot of time on enabling all the scenarios and that could be a big time investment.

supports both public and private repos

See above comment about git on path versus using git libraries. I think if we used git on the path it makes it easy to support both public and private repos. We would certainly want support for both here.

supporting hosted repos other than just GitHub

There is nothing specific to github here, just git.

will there be additional switches that enable getting a template from arbitrary commits? Branches, Tags, Hash

With sharing templates if we add git support we will have three providers; folder, nuget and git. Here is how I view the primary user scenarios for each.

• Folder: two primary scenarios here.
  
  
  
  • Template developer
  
  
  • Sharing templates across an enterprise
  
  
• NuGet package
  
  
  
  • Good for sharing with a large audience and for scenarios where users should be able to create any version ever shipped. This is ideal for templates shipped by the ASP.NET team and other popular template packs.
  
  
• Git
  
  
  
  • For the "rockstar developer" who wants to create awesome samples and share them
  
  

For git there are two things to remember here.

• It's designed for the case where a developer can put together a sample and easily share that.
• git has a lot of options regarding what branch/tag/commit to clone.

At least for the first release I'd like to keep it simple. At most we could consider adding support for branch, but I'd like to avoid that as well. If you're sharing a template with git, I'd like for the guidance from us to be: have your templates setup in the main branch and instruct users to invoke dotnet new --install <repo-url>. I don't want to complicate that by having instructions like dotnet new --install <repo-url> --commitid <id>. For those scenarios the template developer should instruct the user to use git to get the specific commit locally and then run dotnet new --install <folderpath>.

how is the version filter going to work or is this even apporpiate for the git provider

Version would not apply to the git case. It would be ignored, or we would throw an error if passed in. I think error is preferred but not sure.

how does the update scenario work? User installs a template and then template updates are later committed and pushed

See my comment above about update.

both ssh and http supported for this feature

See my comment above about git on the path versus git libraries.

how about a validation switch to test that repo is setup correctly so that we can avoid clippy feedback about a 'looks like you're trying to clone a git template'

If the user invokes dotnet new --install <git-url> and there are no templates we should likely throw an error. I'm not sure if we can inspect the git repo ahead of time to look for .template.config\template.json files. I can chat with @mlorbetske about that.

[RehanSaeed]

+1 on not having a stict predefined folder structure.

How does updating from a NuGet package work currently? If I install a template NuGet package, then release a new version, does it automatically get updated then next time I try to use it? Is there a --update command I'm not aware of?

As a template author, I always want my users to have the latest version of my template and 99% of the time so do my users, who want the latest hotness and fixes. That's why I kind of feel that having to manually dotnet new --update <identifier> every time you want to use a template is the kind of thing people will forget to do. I think the default should be the path the majority will take i.e. give me the latest and greatest.
I like the idea of --changeset or even better --tag for getting particular versions. That will bring it into line with NuGet where you can get a particular version.

[mythz]

IMO it would be ideal if you could look at the version numbers in Git tags for the package to download similar to how Swift resolves which Git dependency to use. So if the user specifies a major version it will get the most recent tag/release for that major version otherwise it uses the latest tag/release.

If there are no tags then you could fetch the master branch although using tags/releases ensures the developer is in control of which templates users get.

[BrainCrumbz]

Given that NuGet provider already supports version, it'd be a good thing to also support that in Git provider, where "version" should be inteded as "tag". So possible examples:

# download latest from Git repo (also works as an update)
> dotnet new --install https://somegit.com/someUser/someTemplates.git
> dotnet new --install https://somegit.com/someUser/someTemplates.git::*

# download specific version (tag) from Git repo
> dotnet new --install https://somegit.com/someUser/someTemplates.git --tag some-tag
> dotnet new --install https://somegit.com/someUser/someTemplates.git::some-tag

Maybe not as a first start, but in the medium term it should be possible to pick a specific version. Of course, the :: syntax is to keep it the same as Nuget, so that template user does not have to remember two different command line syntaxes.

If there has to be a "convention" on branches, just consider main. Only support tags, no commit hashes nor other ways identifying git commits. No restriction on directory structure: just look for existing .template.conig\template.json files found.

If template version is supported (whether from Nuget or Git), there should also be a way to see what version you currently got installed on machine, so dotnet new -l could show that as well in a column. Or maybe in some detailed output just for a single template: dotnet new -l some-template-id.

HTH

[motowilliams]

I hope I'm wrong _(or just can't find it / figure it out)_ but it seems libgit2sharp doesn't easily support SSH. Not a big deal if there are no plans to support SSH but I assume that would be a use case (it would be for me).

[thecodejunkie]

I think adding a git provider would be absolutely killer. I'd love to just have to push to git, with a tag, to release a new template. Adding a nuget, just for the sake of being a delivery mechanism is going to add fluff in order to create and maintain these templates. Realistically you'd need to setup a build script to create these for you, to remove the manual labor

[mlorbetske]

This is being worked on in #660

[motowilliams]

Looks like #660 has stalled. What is going to be the method of standing up a project ala dotnet new some.git.repo.url?

[mlorbetske]

@motowilliams I've commented on the remaining work in #660. Also note that this is an installation case, not a direct invocation of new on an URL pointing to a repo as the template specification - that work is not planned.

[donJoseLuis]

closing as the last activity was over 2 years ago. Please reopen if this is still desired.