We have a project that has already been deployed to one of our STA environments. We made few changes in it to include two new dll’s(no code changes though) in bin.
After building the project in TeamCIty, we could see those dll’s in the nuget package.However they are missing once Octopus deploys them. I could see that Octopus is always pulling the old version nupkg from the package cache.
Is there anyway we can force Octopus to pull the latest version package from TeamCIty?
I have attached the screen shots.
Hi Abhinand,
Thanks for getting in touch! Octopus is not really designed to work with package versions that are the same but have different content. We use the practice that a version in both package and release contains a static artifact and you can rely on a release to have the correct version of files. Due to things like our package cache and snapshots, we really suggest that if you want to make changes including adding additional files you change the package version and create a new release.
The behaviour you are seeing is by design. You can attempt to delete the files from the package cache and re-upload to try to get around it, but there is no easy way to bypass the system.
Vanessa
Can you please look at the highlighted part in the attached screen shots? The package version has changed, still Octopus doesn’t include the newly added dlls.
Hi Abhindand,
If you look at your release screen for 1.1.0107.22 and look at the packages listed for that release, what number does it have? We only use the package versions listed for a release and a release has a snapshot of a package version.
How did you create the release, why is it looking for a different package? Did the package exist when the release was created?
Vanessa
For 1.1.0107.22, there was an change in artifact dependency in TeamCity on two other projects. No code change. When I build this in TeamCity, I could see it has created a .nupkg with the new dlls that were added as part of the artifact dependency.
However once I deploy this package through Octopus(from TeamCity using Octopus Plugin) I do not see those dll’s in the bin folder any more. I could see from the task log that it is always pulling the older .nupkg from the cache.
I have similar issue with another project now. This time the only change was changing the ‘Build Action’ property from ‘Content’ to ‘None’ for Web.Release.Config and from ‘None’ to ‘Content’ for INT, STA and PROD. This change was done to fix the config transform issue. However Octopus is still pulling the old package which doesn’t include these transform related changes.
The release number has nothing to do with the package version number. They aren’t related unless you make them related. Octopus will ALWAYS use the package version specified for a release, it will never change, even if your packages do.
To release a new package, you need a new release with the correct package associated.
In your very last screenshot, release 1.1.0111.20 will ALWAYS use package 1.1.1208.16. If this is incorrect, you are creating your releases wrong, and haven’t associated the create release command correctly with your builds.
So if this is your problem I would need to see how you are creating releases. It may however be easier for you to view our TeamCity integration videos as will give much more information than I can. https://octopus.com/videos Specifically ‘Triggering Deployments from TeamCity’ would be where I suggest you start.
Vanessa
When TeamCity builds a project it associates the artifact (nugget package) with a unique version number which in my case is of the format %Version.Major%.%Version.Minor%.%env.BUILD_START_MONTHANDDAY%.%system.build.number%
I use the same version number from teamCity as the release number for Octopus.
I’m attaching all the relevant screens shots.
ServerTasks-2544.log.txt (6 KB)
You are missing the additional commands to define the package version which is both in the video I linked and our documentation: http://docs.octopusdeploy.com/display/OD/TeamCity see: Triggering deployments from TeamCity
Vanessa
I will try that… but i have one more observation.
I just changed the values of Version.Major and Version.Minor in %Version.Major%.%Version.Minor%.%env.BUILD_START_MONTHANDDAY%.%system.build.number% to 2 from 1. The resulting version number for the new build is 2.2.0111.21.
And now I have noticed that everything went well. Octopus took the latest version and deployed it instead from the cache like before. Any guesses?
Ok… I can now confirm that without mentioning the version number in “Additional command line arguments:” in “OctopusDeploy: Create release” step in TeamCity, Octopus Deploy will not be able figure out which is latest build version.
Octopus does a regular string comparison to determine the latest version as a result it identified 1.1.1230.14 as the latest version and not 1.1.0107.26 .
I’m closing this conversation now. Thanks a lot for your support.