I’m getting these very non-informative errors when pushing packages to Octopus. It happens on all the projects using OctoPack. I have upgraded Octopus Server AND all OctoPack packages in my projects.
How do I debug this? I’ve searched these forums and found a similar problem in a different thread, but it was closed and claimed the error was fixed in some version, but that version of both NuGet and OctoPack/Octopus Deploy is way outdated now. I’m using the latest versions.
Thanks for reaching out! Couple of debugging tips:
When pushing packages, the error 500 usually means that you are trying to push a duplicate package (same combination of ID + version). Are you always testing the same package or are you trying different ones? You might wanna try this out: https://octopus.com/docs/how-to/push-a-nuget-package-that-already-exists
Have you checked the size of the package that Octopack creates? When it creates a package, it puts it on a folder called /Octopacked/ somewhere on your solution directory. You can see the full path in the Octopack log.
The version number does increase by each build (using TeamCity). The size of the packages in /Octopacked/ is correct (~4 mbish), while 0 bytes in the Octopus\Packages\xxx\ folders on the Octopus Server.
I’ve checked the log file and found this:
2017-03-13 16:56:26.2942 68 ERROR Unhandled error on request: http://192.168.10.xxx:yyy/nuget/packages/ 1a942648f8be43c791434ceb3ecfce87 by xxx\yyy : The process cannot access the file ‘C:\Windows\system32\config\systemprofile\AppData\Local\Octopus.Server\Temp\pkgpush-YJCZHJZ7\package.nupkg’ because it is being used by another process.
System.IO.IOException: The process cannot access the file ‘C:\Windows\system32\config\systemprofile\AppData\Local\Octopus.Server\Temp\pkgpush-YJCZHJZ7\package.nupkg’ because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream…ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Octopus.Core.BuiltInFeed.BuiltInPackageRepository.AddPackage(IndexedPackage package, String srcPath) in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Core\BuiltInFeed\BuiltInPackageRepository.cs:line 178
at Octopus.Server.Web.Api.NuGet.PackagePushActionBase1.Execute() in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Server\Web\Api\NuGet\PackagePushActionBase.cs:line 81 at Octopus.Server.Web.Infrastructure.Api.Responder1.Respond(TDescriptor options, NancyContext context) in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Server\Web\Infrastructure\Api\Responder.cs:line 145
at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
at Octopus.Server.Web.Api.OctopusRestApiModule.<>c__DisplayClass0_0.<.ctor>b__0(Object o) in Z:\buildAgent\workDir\eec88466c176b607\source\Octopus.Server\Web\Api\OctopusRestApiModule.cs:line 46
at Nancy.Routing.Route.<>c__DisplayClass4.b__3(Object parameters, CancellationToken context)
I have tried to restart the system but it doesn’t help.
It seems this problem has resolved itself without my intervention. Yesterday it did not work. Today it works. Nothing has changed between then and now.
I guess Octopus Server ran some scripts during the night that fixed this.
The process cannot access the file 'C:\Windows\system32\config\systemprofile\AppData\Local\Octopus.Server\Temp\pkgpush-YJCZHJZ7\package.nupkg
Its possible that the above error is being caused by an anti-virus scanner locking down the file, preventing it from being fully copied to the C:\Octopus\Packages\ directory and ending up with a 0kb file.
If you have an anti-virus in place, you might wanna consider white listing the directory where those temp packages are being dropped.