I configured TeamCity to deploy a NuGet package (say 0.15), and afterwards I use a build step with octo.exe to create a release. However, it seems the latest version octopus sees while this build step is running is the previous NuGet packge (0.14) being deployed.
See also the following TeamCity log (replaced some values for privacy reasons with xxx’s):
[00:39:56][Step 3/3] Starting: C:\Octopus\Octopus\Tools\octo.exe create-release --server=http://xxxxxxx/api --project=xxxxx–version=0.39
[00:39:56][Step 3/3] in directory: C:\TeamCity\buildAgent\work\10bad649fdfd7cca
[00:39:56][Step 3/3] Octopus Command Line Tool, version 22.214.171.124
[00:39:56][Step 3/3] Finding project: Hayman
[00:39:56][Step 3/3] Handshaking with Octopus server: http://xxxxxxxx/api
[00:39:59][Step 3/3] Handshake successful. Octopus version: 0.9.620.4
[00:39:59][Step 3/3] Finding environments…
[00:39:59][Step 3/3] Finding steps for project…
[00:39:59][Step 3/3] Getting latest package versions for each step…
[00:39:59][Step 3/3] 1. xxxx - latest: 0.38
[00:39:59][Step 3/3] Creating release: 0.39
[00:39:59][Step 3/3] Release created successfully!
[00:39:59][Step 3/3] Process exited with code 0
If you go to the Create Release page in the Octopus web UI immediately after the build completes, what versions does it show in the package version dropdown?
I think the nuget package gets published after the run based on the results I see. When I run the build without creating a release in teamcity, the versions matches.
As the build is run by teamcity, I find it hard to actually debug this. While thinking for a solution, may I ask why you retrieve the latest version from the nuget package? Shouldn’t octopus use the version I supplied?
-version parameter to Octo.exe is the name to give to the release, not the version of a package. That might seem strange, but it makes more sense once you imagine a project with multiple packages:
The release number (
-version) for that project might just be “1.0”.
There is an open pull request for the Octo.exe tool to allow specifying a specific package - I’m going to merge it in tonight, and that might solve your problem.
Hope that helps,
Paul, can you please make a comment in this question once the merge is done and available? I’m having the same issue.
The current version of Octo.exe should now support this.
Was this ever fixed? Or is it a configuration problem on my end?
This post is two years old but it’s happening to me right now (version Octopus Deploy 126.96.36.1995). The previous release is deployed and the release number is shown different (more current). See attached screen shots. Team City build 188.8.131.52 and publishes the nuget pacakge (via octopack). I can see the nuget package is there with the latest number, however octopus is deploying the release that can before 184.108.40.206, and the reporting that it deployed 220.127.116.11, but that isn’t what is actually deployed.
If you’re using TeamCity’s built in NuGet feed to host the packages, TeamCity doesn’t make the package available in the feed until the build completes (by design). The only solution is to set up a chained build in TeamCity. You can read more in the section “Tip: Delayed package publishing” on this page:
Alternatively, you can make TeamCity push the packages to the Octopus built-in repository using TeamCity’s NuGet Publish runner. You can then have Octopus deploy the packages out of the Octopus feed instead.
Hope this helps,
Thank you. I do remember seeing that in your video and thinking “oh crap, now I have to pay for teamcity because adding that many extra builds puts me over the free limit”. But that’s OK.