Release is not setting the proper package version from TeamCity plugin

(Apologies for posting this in both discussions. When I initially created the ticket, I wasn’t aware it was in ‘Questions’ vs ‘Problems’. This is certainly a problem that is gating progress.)

I have projects built from multiple branches using octopack, generated from the visual studio runner in TeamCity. Since the plugin does not allow changing the nuget package id like MyApp..1.0.0, I am using a package version like 1.0.0-. This means all builds us the same Nuget package Id of MyApp. I’m using the OctoRelease runner and explicitly creating a release in the Octopus Deploy project to 1.0.0-, but Octopus keeps assigning whatever version number is highest to the release, ignoring the - tag specifier (I believe called a “prerelease” tag in SemVer). This prevents me from getting the proper package into the release.

For reference, I’m doing exactly this: http://help.octopusdeploy.com/discussions/questions/1786-octopack-build-in-release-and-debug-mode

From the previous tickets I’ve seen, this is supposed to work when creating a release and specifying the package version, as opposed to creating the release in the UI. I would prefer to override the Nuget package ID itself, but octopack doesn’t seem to support that. I’ve seen that you can specify a Nuget spec file explicitly, but I don’t want to have to create 3-4 specs per project just to support this, and it’s not clear my spec would be equivalent to what is generated by octopack. This seems like a very common use case. Using the latest 2.5.10 release, TeamCity 8.1.x, and latest TC plugin.

This may be related to #1249, but is a slightly different use case. I’d also tried scoping variables to change the package id parameter from the step template, but that also didn’t work. So, this also is still a problem.

You should consider pulling https://github.com/OctopusDeploy/OctoPack/pull/55 or making a similar change.

This is currently gating my development of branch specific deploys.

Hi Rick,

Thanks for getting in touch! And thanks for the feedback.
Could you provide us with a screenshot of your TeamCity runner, as like you have said it should work fine. this might give us a better idea of the problem you are having.

We will be evaluating and merging the PR in the next week.

Thanks!
Vanessa

Hi Vanessa,

I’ve added a screenshot of the runner (TeamCity1.png) and the build log showing octopack output. The TeamCity2.png shows exactly what I’m describing above. For now, I’ve worked around it by creating a Create Nuspec runner that creates a nuspec file and uses TeamCity to replace the value of the element in the file by appending a variable to the name (which I believe is from the Assembly Title or Name). I hope that helps.

I was also unable to get the Package template step to use a variable to replace the nuget package id, so I created separate package process steps, each referring to the nuget package id for each branch (i.e. MyProject-DEV, MyProject-PROD, etc). I’m watching the other tickets for that to be fixed.

We are have the exact same setup and issue. We have several branches, DEV, QA, UAT and PROD. Each of these deploys to separate environments. We are also using versionnumbers of the same format 2015.2.1 (year.release.buildnumber)

Dev environment will have many builds and a large buildnumber, QA, UAT and prod will have significantly smaller versionnumbers. Octopus will deploy the highest packageversion which cases packages from DEV to be deploy in all environments.

I’ve tried to set up different projects in Octopus for Dev, QA to be able to pick up packages from different feeds/libraries, but the TeamCity NugetServer server integration only lets mes specify one feed url. If I could set up one feed for each branch I guess the problem would be solved??


Christian

Hi Christian,

From TeamCity you can specify --packageversion=<your version> when you define the --version=<your version> in your build runner this will let you define which package per release version.

Let me know if it helps with your issue.
Vanessa

1 Like