Add chocolatey-recommended metadata #30
Conversation
|
@heaths, |
|
✅ Build vswhere 1.0.44-beta+g9d12821f18 completed (commit 9d12821f18 by @heaths) |
|
@heaths the recommendation here would be to use P.S. As a side note, what is the AppVeyorBot? What is controlling that? |
|
@gep13 that would require completely replacing the existing project and writing my own. I can put it on the backlog but the whole point of using either NuProj (VS2015 and older support) or Nugetizer 3000 (planned VS2017 support from the NuGet team) was to avoid spending resources on maintaining a build when other projects exist. It would benefit the community if NuGet supported reading and writing custom metadata. AppVeyorBot is the bot used by https://appveyor.com, which is a popular cloud build system that we (and many other projects) use for PR and CI builds. |
And I don't disagree with this. The point that I was making was that, for now, that is the only thing that differs between the packaging requirements for NuGet and Chocolatey packages, but this might not always be the case. Since Chocolatey is already installed on AppVeyor, you could have an additional build step in your appveyor.yml file that makes a call to
Yip, I am very familiar with AppVeyor, but didn't know that they had a bot for writing notifications directly into PR's, will have to have a look at that. |
|
Ultimately, when you have many more build steps in your PR and CI builds that don't run on local dev boxes, mistakes happen (I maintain a number of build definitions for the Visual Studio setup engine). The point of having the NuProj project was to make sure when devs build they find any problems before pushing and triggering a PR build. I'm not adamant about it and would likely accept any PR to change our appveyor.yml file (which you can find information how we trigger the PR bot) and drop the nuget package project since NuProj isn't and likely won't be supported in VS2017 (I know the maintainer). |
Yip, I totally understand that idea. As one of the maintainers of the Cake project, we use the exact same build script to do:
On 10 different CI Servers across 3 different operating systems. Where we differ in approaches is that I would use external tooling, i.e. nuget.exe and choco.exe directly to do the packaging/publication work, rather than using a project approach. The reason I suggested doing the work in the appveyor.yml file is that I didn't see any other way with the current implementation, but I definitely agree that having the same build steps happen locally as on the CI Server makes total sense, and something that we advocate when using Cake. |
|
As a side note, we currently have an open PR for adding VSWhere Aliases into Cake, which would allow something like the following in a build.cake file: Which would return all the installation paths for Visual Studio. |
|
I'll consider options. We release from a VSTS build definition so we can real-sign the binaries so that would need custom build tasks as well as our appveyor.yml, thus necessitating synchronization. This is why I used a project within the solution that supports build via |
|
I found https://www.nuget.org/packages/chocolatey/ so that should help things. I can put that in .nuget\packages.config for a global package to restore at the beginning of the solution build. |
|
✅ Build vswhere 1.0.57+g6a7bd6c827 completed (commit 6a7bd6c827 by @heaths) |
|
Without the ability to pass properties to I'm leaving this blocked and will see about adding support to nuget itself to at least pass through custom metadata. |
|
@heaths did this get implemented? |
|
Yes, see #100 and the results of that work at http://chocolatey.org/packages/vswhere. Thanks for releasing the new version! |
This is current blocked on nuproj/nuproj#281.