I have a build setup to deploy instances of the same service to different directories on our destination service. The steps are all part of a single ‘Deploy Service Package’ step, and all utilize the exact same nuget package when deploying. The deployment proceeds normally for a time, then suddenly fails with a ‘The package was not found on this machine’ error. Re-trying the deployment and skipping the steps that worked previously allows the deployment to complete successfully. Is this expected behavior?
I don’t see anything in the logs to indicate that the nuget package is getting deleted prior to the failing step, the step just fails. I’ve seen cases where 5 and 7 steps run, I’ve tried ‘retrying’ the deployment and that doesn’t seem to effect the outcome.
As a follow-up, I have been able to get the deployment to fully complete when running a ‘Try Again’ from the server [but only once ever, and it has failed many times since], but it still fails when triggered from TeamCity. I’m trying to determine from the Trace logs what could possibly be happening, but what I’m seeing is that for some reason the ‘rolling deployment’ decides to re-use a directory it had previously used, so the sequence goes something like:
package_version…
package_version_1…
package_version_2…
package_version_3…
package_version_4…
package_version_5…
package_version_6…
package_version… <- here is where things explode
I’ve tried turning on guided failure, package re-download and all the other various bits to no avail. It feels like there is a race condition or some such that allows the initial directory to be reused again. This package, unlike many other packages on the server, also seems to be deleted after the ‘final’ step prior to deployment…
Hi Ben,
Thanks for sharing this, it does indeed look to be the same issue. Can you try upgrading to 2.4.2? We’ve changed how retention policies work so this should go away:
Paul