OctoPac is creating a release and deploying 1 project nuget package correctly but the second project in the same solution it is deploying the previous version of the nuget package.
Setup
We have a single solution.
Inside are multiple projects that get built into nuget packages.
The build number is 1.0.%build.counter%
I have attached the logs.
You will notice that on line 482:
482: [Publishing artifacts] Collecting files to publish: [C:\TeamCity\buildAgent\work\34d690515b0b72bd\CoffeeTalk\obj\octopacked\CoffeeTalk.1.0.59.nupkg]
It is creating CoffeeTalk.1.0.59.nupkg
You will notice that on line 1354:
1354: [Publishing artifacts] Collecting files to publish: [C:\TeamCity\buildAgent\work\34d690515b0b72bd\RoastCentral\obj\octopacked\RoastCentral.1.0.59.nupkg]
It is creating RoastCentral.1.0.59.nupkg.
But then on lines 1439 & 1440, it deploys the wrong version of Roast Central.
1439: [Octopus Deploy] 1 Deploy CoffeeTalk 1.0.59 Latest available in NuGet repository
1440: [Octopus Deploy] 2 Deploy RoastCentral 1.0.58 Latest available in NuGet repository
Thanks for getting in touch and thanks for the detailed question. I’ve reviewed your TeamCity log and I believe it’s a timing issue. The Octopus TeamCity documentation page (http://docs.octopusdeploy.com/display/OD/TeamCity) states the following.
Tip: delayed package publishing
NuGet packages created from your build won't appear in the TeamCity NuGet feed until after the build fully completes. If you plan to trigger a deployment during a build, this creates a problem: the package won't be in the feed until the build is published, so you won't be able to deploy it.
The solution is to configure a secondary build configuration, and use a snapshot dependency and build trigger in TeamCity to run the deployment build configuration after the first build configuration completes. The video below demonstrates how to do this ...
Therefore, I think it’s likely coincidental that one of the two packages exists in in the TeamCity NuGet feed at deployment time. I’d suggest reviewing the video at the bottom of the TeamCity documentation page or consider using the built-in Octopus NuGet feed instead of the TeamCity one (see http://docs.octopusdeploy.com/display/OD/Package+repositories). If you use the built-in feed, then you simply have to add a couple of NuGet Publish steps to your TeamCity build configuration and then run the deployment. In this scenario, the latest packages will be available for the deployment immediately.
Thanks for the reply. I’m happy to hear you got it up and running. In regards to NuGet feeds, there are a few advantages to using the built-in one over TeamCity.
Speed: This is the big one. The Octopus server already has the packages so it doesn’t need to download them at deploy time. Anytime it needs to work with packages it’s much faster to query the local repository than make a request to a remote server.
Retention policies: This is subtle point but very beneficial. Octopus supports retention policies on the server, Tentacle and the built-in NuGet repository to cleanup deployment artifacts. Octopus server Lifecycles can keep the last X releases and the built-in NuGet repository supports removing packages that are no longer associated with a release after a period of time. The key is that the everything is integrated and can work better together. See http://docs.octopusdeploy.com/display/OD/Retention+Policies for more info.
Both approaches work so it comes down to what works best for you in your environment.