Home → Questions →

I need some help with automated versioning and deploying a nuget package.

• Edit

Tory

17 Aug, 2019 09:59 PM

In my appveyor.yml I have the following build:

version: 1.7.{build}
build_script: - ps: 'dotnet pack -c Release -o "$(pwd)/artifacts/" "-p:Version=${env:APPVEYOR_BUILD_VERSION}"'

So, you can see a build would result in an artifact like this: /artifacts/MyPackage.1.7.22.nupkg thanks to the -p:Version flag to dotnet pack.

This does not play well with tagging.

For example, if you add a deployment to GitHub releases, and you set it to only deploy on tags, then how could you possibly know which tag to use? IE you would tag 1.8.0 and AppVeyor might create an artifact with 1.8.212. Which do not line up.

What is a way around this?
Should I not be using tags to deploy?
Is there a way for my tag version to completely override my appveryor version, or Is that the wrong way to do it?

1. 1 Posted by Tory on 17 Aug, 2019 10:32 PM

   

   I guess I cant edit my question but I have thought about a few things.

   Setting tag in the provider solves the version mismatch problem: tag: v$(appveyor_build_version)

   However, it then makes the manual tag useless. Aside from the fact that it was used to trigger the deployment.

   • Edit

2. Support Staff 2 Posted by Owen McDonnell on 19 Aug, 2019 06:16 AM

   

   Perhaps I'm missing something, but whats wrong with APPVEYOR_REPO_TAG_NAME?

   • Edit

3. 3 Posted by Tory on 19 Aug, 2019 02:43 PM

   

   Using APPVEYOR_REPO_TAG_NAME all over will un-automate the version. And will require a custom script to differentiate a regular CI build/PR build from a deployment since you dont tag the former.

   • Edit

4. Support Staff 4 Posted by Owen McDonnell on 19 Aug, 2019 05:14 PM

   

   What about setting a custom variable based on whether APPVEYOR_REPO_TAG is true, which it is for builds triggered by tag?

   • Edit

5. Ilya Finkelshteyn closed this discussion on 19 Oct, 2019 09:01 PM.