Tool Request: List installed dotnet new template version
VictorioBerra opened this issue · comments
I would love a tool to show installed dotnet tool versions.
I went ahead and took a stab at it: https://github.com/VictorioBerra/TemplateVersions.Tool
But i am still trying to figure out MyGet and appveryo and automated versioning and all that so I can get this thing onto NuGet.
I tried examining natemcmaster/dotnet-serve as an example for auto versioning and releasing to nuget, but its crazy complicated. Is natemcmaster/srihash-cli a decent example of how this should be done?
the dotnet-serve repo is using Azure Pipelines, so not really a good example if you want to use AppVeyor. And srihash-cli is pretty stale, so also not a create sample. But here are some relevant docs on how to setup AppVeyor to auto-version your build https://www.appveyor.com/docs/build-configuration/#build-versioning and how to release to a nuget server https://www.appveyor.com/docs/deployment/nuget/.
I saw you cleaned up the appveyor stuff in srihash-cli, that helped me a lot.
So I have a question about deploying now. The way your appveryor/csproj works in srihash-cli is that it will only deploy if you push tags, but I noticed I can push "1.0.0" even though my appveyor.yml has version: 0.1.{build}.
When I went to GitHub, GitHub showed the release as "1.0.0" but because of the build_script and version tags in the yml, my nuget package resulted in a "0.1.5".
How do you reconcile this? When releasing 1.0.0, would you have manually changed the version node in your yml? Would you just release v.1.0 and then let the build number just be whatever it is?
The old, more complicated code I deleted yesterday in srihash-cli is how I was working around that problem. I think what I would do now is change the GitHub deployment step to run on all builds of the master branch, but only create a GitHub release draft.
How does this solve the versioning issue?
Im trying to think through this. So, if you did that, that would mean you would no longer be relying on tagging (for GitHub releases only though). Now, AppVeyor would be in control of the SemVer which you would have to remember to bump major or minor (because you do this: 1.7.{build}).
After that, you would be required to manually open Github and then publish your draft.
After that, I am lost.
As someone who does not use MyGet, im guessing now, MyGet would see the newly published GitHub release, and then add it to the feed and pass it upstrea to NuGet.org?
How does this solve the versioning issue?
The version of the package is completely controlled by the appveyor.yml file. Once a build is done, it stages a draft release on github.com along with a draft github tag.
- provider: GitHub
tag: v$(appveyor_build_version)If I decide the build is good to go, I publish the draft release on github, which automatically tags the source code used to make that build.
As someone who does not use MyGet, im guessing now, MyGet would see the newly published GitHub release, and then add it to the feed and pass it upstrea to NuGet.org?
You don't have to use MyGet. You could configure AppVeyor to publish directly to nuget.org, or you could do it manually by downloading .nupkg files from appveyor after a build is done. In my configuration, MyGet doesn't interact directly with GitHub. I use it as an intermediate nuget feed for testing purposes. On my higher-traffic projects, it's nice to have a place to stage daily builds where contributors can try out unreleased bits before they go public to the rest of the world on nuget.org.
This is very helpful, thanks! One last question (probably lol) do you always protect your master branch in GitHub? I noticed you created and accepted your own PR on srihash for your appveryor changes.
Yes, I protect master but don't require PRs. I don't usually do PRs to myself, but in this case I did because it's hard to test appveyor without making a PR.