I have a deployment project set up with automatic release creation enabled. The project is deploying two nuget packages that are pushed to the internal Octopus feed from a single Team City build that pushes in total 4 nuget packages (A, B, C and D) using msbuild and the OctoPackPublishPackageToHttp property. The automatic release creation is configured to use the last pushed package, package D, as a trigger. I’ve verified that the packages are pushed at around 10 sec intervals and that package D is the last one to show up on the page “Library > Packages” in Octopus Deploy. However, I keep getting the following error in the logs:
2015-02-13 09:59:31.2751 WARN Unable to automatically create a release for project 'X' when package D version 2.17.0-Beta20150213095810 was pushed: Failed to find latest version for package A
What suggestions do you have to resolve this issue?
FYI I’m running Octopus Deploy 188.8.131.528
Are you able to supply us with a full TeamCity build log on one of the instances where you have had this issue occur.
It might be a case that because of the naming, package A has a package that is dated later but a higher version.
A screenshot of your packages in the repository might help us figure this out.
I’ve attached a screenshot of the Octopus Packages Library at the point where packages A, B and C have been pushed to the feed but package D is still not uploaded (it is pushed around 5-10 sec after package C). All package Ids start with the same prefix and you see the rest of the names in the screenshot. They all have the same version.
In this screenshot, the previous version was 2.17.0-Beta20150213182205 and the latest version (the one being pushed to the feed) is 2.17.0-Beta20150213183333.
Note that the error in the original post is from an older attempt to automatically deploy a release so the package version doesn’t match the versions from the screenshot above.
Yeah it’s all looking fine. So one thing that has occurred to me, does Package A use a variable in the step package name?
None of the packages can use variables in the names if using Automated Release Creation.
No all steps are using fixed package names, no variables.
Sorry for the delay I am at a bit of a loss here and there aren’t any logs made at this point that would help.
So a few questions: does the release always choose the immediately-before-last package A or a specific package A ?
Could you restart the Octopus Server service and try this again. We rebuild the index for the internal repository on restart.
I’m not sure what you mean. When I manually create a release then Octopus chooses the latest version of all packages. When the automatic release creation fails, it is trying to create a release for the latest version of the packages but doesn’t find the latest version of package A even though it is present in the package feed.
We have restarted the Octopus Server and even re-installed it on another server, with no luck.
Can you provide your TeamCity Build log?
I’m having the same issue. My build is running out of TFS Build 2010 and I’m trying out this functionality.
I have an Octopus project that is deploying 3 nuget packages. I’ve tried setting Octopus to create a release based on each of the packages and each time I’ve gotten an error along these lines:
2015-03-10 07:22:52.7611 197 WARN Unable to automatically create a release for project 'DBUp' when package Local version 184.108.40.206-dev was pushed: Failed to find latest version for package Central
The build log from TFS shows that the projects are being built in the order of:
Built Central.csproj for default targets.
Built Data.Common.csproj for default targets.
Built Core.csproj for default targets.
Built Common.csproj for default targets.
Built Local.csproj for default targets.
The Local project is the last one built in the build log, so having it be the package that creates the release should be ok. I’ve manually created a release of this project and it finds all the packages.
I’m running Octopus 220.127.116.11, and I’ve restarted the Octopus Server to trigger a reindex of packages.
To work around I’ll edit my TFS Workflow and add a custom step to create a release, but I was really hoping to avoid that if possible.
Are you able to provide the full TeamCity build log and a screenshot of your project process.
I created a private discussion and linked my log attachments to that. I can’t post that information publicly.
Link to private discussion
We think we have found the cause after getting the build logs from Joe.
I’ve created a GitHub issue which you can track here: https://github.com/OctopusDeploy/Issues/issues/1512