Home → Questions →

NuGet release/prerelease deployment based on tag

• Edit

soloydenko

04 Aug, 2016 06:58 AM

I have a project setup that has a section responsible for package deployments to NuGet.org:

- provider: NuGet
  name: production
  api_key:
    secure: O40j/Pdb5Tw3LGduh9X++gU/fVBanydt/MAZtNbwIeQT9L2nbadqFNOku9p2wty4
  on:
    branch: master
    appveyor_repo_tag: true

I noticed that every time I tag the master branch in the GitHub repository for my project, a prerelease version of a package is built and deployed. My question is whether it is possible to tell appveyor make it a release deployment for tags that look like "1.0.1", "1.0.2" etc, whereas prerelease deployment for any other tags, say "1.0.1-b00123".

Also, is there any document that suggest any other convenient deployment strategy? I mean, a strategy that is reliable, automated, and simple in setting up and usage?

Thank you very much! AppVeyor is awesome!

1. 1 Posted by Ilya Finkelshte... on 04 Aug, 2016 11:24 PM

   

   Hello,

   Thank you for good words!

   According to https://docs.nuget.org/create/versioning, per my understanding, prerelease version is version appended by some string like “-alpha”. In your https://github.com/another-guy/Mirror/blob/master/Build.ps1, you generate revision and unconditionally add it with --version-suffix=$revision statement in line 30. Per https://docs.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-pack --version-suffix “updates the star in -* package version suffix with a specified string”. Therefore I believe that if you add some --version-suffix it will be pre-release.

   Try to do the following:
   Parse APPVEYOR_REPO_TAG_NAME environment variable

   - If tags that look like "1.0.1": don’t add --version-suffix or not at all.

   - If tag looks like “1.0.1-b00123”: add --version-suffix=b00123

   What about deployment strategy, we discuss it case by case, and do not have universal solution. Your approach looks good :)

   --ilya.

   • Edit

2. 2 Posted by soloydenko on 04 Aug, 2016 11:46 PM

   

   Thank you, Ilya.

   Your suggestion regarding the --version-suffix key looks reasonable. I'll give it a shot and see how it goes.

   • Edit

3. 3 Posted by soloydenko on 05 Aug, 2016 06:17 AM

   

   Good news! As per your recommendation I have modified my Build.ps1 script and it is now capable of building both prerelease as well as release versions of the package depending on the commit tag's value.

   Unfortunately, I had to add an additional (pretty fragile) code that checks "compatibility" of tag version against the version specified in project.json. This is needed to prevent accidental releases without prior project.json metadata update.

   $tagOfHead = iex 'git tag -l --contains HEAD'
   $prefixExpected = $tagOfHead + "-"
   $projectJson = Get-Content '.\Mirror\project.json' | Out-String | ConvertFrom-Json | select -ExpandProperty version #| Select-Object -Property version
   
   if ([string]::IsNullOrEmpty($tagOfHead)) {
     $revision = @{ $true = $env:APPVEYOR_BUILD_NUMBER; $false = 1 }[$env:APPVEYOR_BUILD_NUMBER -ne $NULL];
     $revision = "b{0:D5}" -f [convert]::ToInt32($revision, 10)
     exec { & dotnet pack .\Mirror -c Release -o .\artifacts --version-suffix=$revision }
   } elseif ($projectJson.StartsWith($prefixExpected,"CurrentCultureIgnoreCase")) {
     exec { & dotnet pack .\Mirror -c Release -o .\artifacts }
   } else {
     throw ("Target commit is marked with tag " + $tagOfHead + " which is not compatible with project version retrieved from metadata: " + $projectJson)
   }
   

   (See https://github.com/another-guy/Mirror/blob/master/Build.ps1#L29 for details)

   @Ilya, I know this goes beyond support staff "duties" but if you have spare minute and desire to help further, could you review my approach and suggest improvements? I am very new to powershell and CI and automation tools in .NET world.

   • Edit

4. 4 Posted by Ilya Finkelshte... on 05 Aug, 2016 07:20 PM

   

   Hi,

   I think that script is good, just minor notes

   1. Are you sure you need “-*” in project.json version? Maybe you can just set it to 1.0.2 instead of 1.0.2-* and check if it is equal to $tagOfHead (without introducing $prefixExpected variable at all)?

   2. NIT: rename $projectJson to $projectJsonVersion ☺

   Thank you,
   Ilya.

   • Edit

5. 5 Posted by soloydenko on 05 Aug, 2016 11:55 PM

   

   1. I'd rather leave the "*" in some form. It can be either used as a build number (as it is now) or be an exact match of the tag applied to the commit being build. Not sure which one is better for me. The "*" lets me avoid manual PATCH version (as in SemVer) update. I only need to intervene when MAJOR or MINOR versions should be changed.

   2. Nice catch.

   Thank you for your time again Ilya!

   • Edit

6. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:07 AM.