21

I have set up a build step on TeamCity,as described here, to do automatic release deployments to our test server. But it is not using the latest nuget packages that was build in TeamCity.

Use Case :

Teamcity will create nuget package with version 1.0.0.9, all the dlls that is in the package is the correct version, and the Release in Octopus, that was deployed has got the same version number , but the packages that octopus uses is of an earlier package eg 1.0.0.5.

I have specified the --force parameter on the build step so it should use the latest packages but it is not.

If I manually create a release in Octopus, and select the latest packages it is working 100%

Please can someone tell me if I am missing something.

thanks in advance

Dog Ears
  • 9,637
  • 5
  • 37
  • 54
Captain0
  • 2,583
  • 2
  • 28
  • 44
  • I have set it to look at the packages folder as well, still not pulling the latest packages. – Captain0 Jun 18 '13 at 14:09
  • What is the order of build steps in your team city configuration? – Jason Jun 25 '13 at 02:46
  • Also are you waiting for the deployment to finish before continuing with other steps? Maybe your missing --waitfordeployment. Really need to know the steps your using in Team City to be of much more help. – Jason Jun 25 '13 at 02:51
  • There are 2 build steps, the first step builds the packages and the second step deploys the packages using octopus. Where should the --waitfordeployment flag be added ? – Captain0 Jun 26 '13 at 06:04

6 Answers6

19

I think what you need to do is create two build configurations in TeamCity, one to build and one to deploy with Octopus. Refer to this link that has a small blurb toward the end:

Note that NuGet packages created from your build won't appear in TeamCity until after the build completes. This means you'll usually need 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.

So in my case I created 2 build configurations, then setup a snapshot dependency from the build to the deploy config and also a trigger to kick off the deploy after a successful build.

Nate Rickard
  • 652
  • 8
  • 14
  • 1
    Agreed. You _can_ publish build artifacts _during_ a TeamCity build, but it's done in the background, so you still can't rely on it as far as I can tell. See http://confluence.jetbrains.com/display/TCD7/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-PublishingArtifactswhiletheBuildisStillinProgress – piers7 Sep 24 '13 at 14:24
  • Yeah, I also saw [something similar](http://confluence.jetbrains.com/display/TCD8/What%27s+New+in+TeamCity+8.0#What%27sNewinTeamCity8.0-MetaRunner) in TC 8 using a meta runner after I posted this answer. I would also still go with 2 linked build configs unless absolutely needed or you're trying to stay under the 20 build configs allowed under the free license :) – Nate Rickard Sep 24 '13 at 18:08
  • I have been googling, and this is the best answer I've seen, but doesn't it seem wrong? I don't like having an extra project for each project in order to deploy. – seFausto Jan 31 '14 at 18:50
  • A little sub-optimal, yes. You may want to look into the metarunner approach, which supposedly can do the artifact publishing within a single build config - sorry, I don't have a link, but I remember seeing it somewhere. I've been grouping the build + deploy configs together in their own Subproject to keep things tidy in the UI, and it seems to work well enough for our needs. – Nate Rickard Jan 31 '14 at 22:33
  • 7
    Pushing to the built-in repository in Octopus 2.1 works around this - use NuGet Publish in the TC build, then the Octopus step: http://docs.octopusdeploy.com/display/OD/Package+repositories – Nicholas Blumhardt Feb 28 '14 at 05:02
  • @NicholasBlumhardt, I liked your idea but had problems implementing it. Please check out my question: http://stackoverflow.com/questions/30012948/publish-nuget-package-during-teamcity-build-to-octopus – SiberianGuy May 03 '15 at 10:51
  • Note that getting a 2nd build config to trigger using a Finish Build Trigger on a feature branch may pose challenges. I would suggest pushing your packages to Octo instead of using Team City nuget feed so that you do not require a 2nd build config. – Jeremy F Aug 29 '16 at 18:55
3

It looks like --force is just to force packages to the be re-installed if they have already been installed. Are you using the --packageversion parameter?

ryan.rousseau
  • 1,595
  • 1
  • 11
  • 22
  • I can not use the packageversion, since the website being deployed has got multiple projects and the package version might not be the same for all of them – Captain0 Jun 24 '13 at 06:19
  • Hmm, would it be possible to give them all the same package version? If TeamCity is creating the NuGet packages, can you use the TC build number when creating your nuspec files so that all of your package numbers are consistent for a single build? – ryan.rousseau Jun 24 '13 at 11:48
1

My organization uses Jenkins CI. We use the unique build number as our package version and then deploy that specific package version using the --packageversion paramater.

In the case where we have multiple services that need to be deployed. We have an upstream job / main job that provides the unique build number.

I'd imagine you can do the same thing with TeamCity

Master Job (unique build number) calls jobs A and jobs B with parameter (unique build). Jobs A and B build version (from Master Job). Jobs A and B complete then publish their respective versions.

badazzhindu
  • 913
  • 7
  • 21
1

It could be a few things.

Check out.

http://octopusdeploy.com/documentation/integration/teamcity

You haven't mentioned how your consuming the feeds from Octopus in Teamcity. I would start there.

Next I would use the teamcity action to do your deploy. You asked "Where should the --waitfordeployment flag be added" there is a check box to make sure the deploy has worked before the action can continue.

Jason
  • 840
  • 11
  • 23
  • Ok the flag was checked, the link did not give any information i do not already have. But deployments still giving the same issue – Captain0 Jun 28 '13 at 04:44
  • Is it a key or permissions issue with the agent then? Does the agent machine have access to the nuget package just after its been deployed? – Jason Jul 01 '13 at 00:21
0

In TeamCity I use a Octo Push Packages step and in the Additional Parameters field I specify the --defaultpackgeversion {VERSION} parameter.

This will force Octo to use a specific version of packages instead of just choosing the 'Latest Version'.

Jeremy F
  • 417
  • 2
  • 16
0

There are more possible reasons for the problem.

  1. To see the problems with Octopus go to Configuration -> Diagnostics enter image description here

  2. Another common problem is to use a Package Name #{variable} in a deploy step

    Currently it is not possible and Package Name should be set manually, for example MyWebSite or MyWindowsService. See UserVoice for this feature. enter image description here

Community
  • 1
  • 1
Artur A
  • 7,115
  • 57
  • 60