We push packages to Octopus during a TFS Build. When creating a Release in Octopus and selecting the option to use the Latest Packages available, it can result in the wrong package being used if another build is kicked off or in progress. It would appear in those situations it is still pushing packages to Octopus, which can get picked up during the creation of release.
Is this an Octopus issue or TFS Build concern? I would have thought that packages would NOT get pushed to Octopus until the TFS build is completed.
Can you tell me what version of Octopus you are currently running? We’ve tried to replicate the issue where creating a release is getting the wrong package version during creation but have not been able to see that same behavior.
Can you provide us a step by step process that you take to see this issue.
I would have thought that packages would NOT get pushed to Octopus until the TFS build is completed
How are you pushing your packages to Octopus? Are you using our Push Package step or a nuget push step? It shouldn’t matter, as the package will be pushed to Octopus once your build has reached that step and it has executed. Or, are you saying that the package is pushed before the build step for your application has completed?
We push about 40 packages to Octopus from TFS when we create builds.
A release was being created in Octopus for release .7. During the compiling/building of the project (build .8) on a TFS build server, the packages for build .8 ended up being pulled into the release .7. Seems like it was a timing thing.
In each deployable project, we have an OctoPack nuget package on each deployable project.
Timetable below:
Build .7 was started at 2:56PM and finished in TFS at 3:26PM
Release .7 was created in Octopus at 3:33PM (specifying to use latest packages available)
Build .8 was started in TFS at 3:14PM but finished in TFS at 4:00PM
Thanks for the extra information. Am I right in assuming that you use OctoPack to also push the packages to Octopus (using the /p:OctoPackPublishPackageToHttp MSBuild argument together with /p:RunOctoPack)?
If this is the case, to get around this you could change your TFS build so that the build steps only generate the packages and then at the end (after all packages have been generated) have a Push Packages step that pushes all the packages to your Octopus server. This will reduce the window when packages are being pushed to your Octopus server (as OctoPack pushes the package at the time of generating the package) and should make it less likely for builds to cause this issue you are seeing.
Great feedback. I think you are correct with your assumption. I have attached an example excerpt of the XAML Build Definition. Is that what you are referring to about /p:OctoPackPublishPackageToHttp and /p:RunOctoPack=true being ran together within the tag mtba:RunMSBuild? You can do a quick search on the example.
If that is the case, where would you recommend the /p:RunOctoPack=true be placed in the sequence that I attached? Or the placement of /p:OctoPackPublishPackageToHttp?
Also got some feedback from our technical team and they thought your suggestion would reduce the likelihood of the issue occurring, but it doesn’t really prevent it. Since we add the packages to Octopus through HTTP requests per package, and HTTP is non-transactional, there’s always a window of opportunity for a release to be created in the middle of the upload. Did you have any other suggestion potentially?
Below is an example of what is currently added to every deployable project in the overall solution. There are about 30-40 of these for example.
