ReOpened: Deploying from TeamCity picks up the wrong Nuget package version

Legacy Uncategorised
1

Hi Paul,

I read the thread about “Deploying from TeamCity picks up the wrong Nuget package version” and the explanations are making sense. But if you look at the verbose output of TeamCity the Octopus Plugin seems to get the right version from the feed as far as my configuration is concerned, but still the version before is deployed. I actually don’t want to trigger a separate build configuration which triggers just the Octopus Plugin in order to get the right release.

Is there any other solution?

Thanks for your feedback
Cheers
Michael

2

Hi Michael,

The latest versions of Octopus include a built-in NuGet repository. You can change your build so that instead of relying on the TeamCity NuGet repository, your build looks like this:

  1. Compile code, run tests, create packages with OctoPack
  2. Push packages to the Octopus NuGet repository
  3. Create and deploy release

This means you don’t need the separate build configurations anymore.

Hope that helps!

Paul

3

Hi Paul,

Thanks a lot. I’ll try that tomorrow.

Good night
Michael

Mit freundlichen Grüßen
Michael Roepke
AOL-IT-Consultant

image002.jpg

image001.jpg

4

Is this documented anywhere?

All I can is the standard documentation ( http://docs.octopusdeploy.com/display/OD/TeamCity ) which unless I’m missing something, is the opposite of what Paul’s comment suggests.

5

Hi Liam,

Thanks for getting in touch! There is a tip part way down the page that states that using the TeamCity NuGet feed means you need to build a secondary build configuration. I guess it is mostly implied that if you use another repository or feed and publish it during the build you won’t have to run a secondary build configuration. I can make that more explicitly explained on that tip.

Thanks for the feedback
Vanessa

6

Hi Vanessa,

First of all thanks for your response. Secondly, sorry for the lack of clarity in my previous comment, despite this you seem to have correctly grasped the question I was trying to ask.
I do agree with your statement about the tip on the documentation page, however I guess what I found more confusing is the fact that the documentation page heavily infers that the recommended configuration is to use the in-built TeamCity NuGet repository rather than the in-built Octopus one. In-fact that configuration that Paul described doesn’t appear to be documented in the Octopus Documentation.
That said, it appears that it is much more straight-forward than I had anticipated to configure TeamCity and Octopus up in this configuration. After your post I re-attempted to get this set-up to work with successful results. So my apologies if my comment seemed a little rudimentary.

Nevertheless if anyone coming to this post finds themselves a little lost like I was here is my quick start guide:

  • As Paul stated, the latest versions of Octopus include a built-in NuGet repository.
    • This is enabled out of the box so you don’t need to do anything to set it up.
    • However documentation can be found here - http://docs.octopusdeploy.com/display/OD/Package+repositories
    • Despite this you can probably figure everything out from the internal page on your Octopus server. This can be found in: Library --> Packages
  • At the TeamCity end you’ll need to add a new build step for publishing the NuGet package
  • It’s pretty straight forward, you just have to fill in the require sections: Packages, API Key (for your Octopus server) and Package Source (URL to your Octopus server NuGet repository)
  • Documentation can be found at - https://confluence.jetbrains.com/display/TCD8/NuGet+Publish
7

Hi Liam,

I’ve put updating this documentation on a list, we will provide proper examples for both. We try not to force a choice in customers. Octopus only has a package repository, but it is not a feed and cannot serve the packages anywhere other than Octopus. We ourselves use the TC feed or our own building, storing and deploying. And other customers use what is best for them. So our stance of trying not to heavily recommend anything specific means that our documentation has a few holes like you pointed out.

That being said after I have said such horrible things about our repository, it is a great place to start, easy to use and means when using Octopus initially or lightly you do not need to purchase another feed provider subscription, which is why we offer it in the mix. I am glad you figured everything out and got this working. And thanks for the how to for people finding this thread.

Vanessa