Hi Ketan, Thank you for the reply.
Using the sysinternals "handle" tool I was able to identify the process that opens the files (msbuild) but also confirmed that this process releases the files before the first Stage Job completes. Between when msbuild exits and the second Stage fails, handle shows no open handles for the a filter that includes a directory from the file that fails to delete. I tried deleting the file via Windows Explorer and it also threw an error, but gave me the name of a process (.NET Core Host) that had the file locked. Based on this it seems that what is happening is: 1. Build phase (Stage 1) completes successfully and creates a .NET Core Host that persists after the build completes. 2. The test phase (Stage 2) somehow destroys the .NET Core Host that was created in the build phase. This behaviour seems both unintuitive and undesirable, but is obviously not a GoCD issue. If anyone has any experience with building .NET Core applications on Windows that can shed some light on this it would be appreciated but otherwise we will continue our investigation off of this group. Regards, Jason On Tuesday, 17 September 2019 01:17:06 UTC-4, Ketan Padegaonkar wrote: > > I'm assuming you're running on Windows. This can usually happen because of > open file handles. Could you use the sysinternals tools > <https://docs.microsoft.com/en-us/sysinternals/downloads/handle> to > identify processes that may be holding onto the files after the build > completes? > > - Ketan > > > > On Tue, Sep 17, 2019 at 2:21 AM Jason Smyth <jsm...@scimarketview.com > <javascript:>> wrote: > >> Hello, >> >> We have several Pipelines that are failing during the "clean working >> directory" task of a Job. The only error message provided is "Unable to >> delete file". >> >> This just started recently but I believe that, until recently, these same >> Jobs did not have the "Clean working directory" attribute set so the issue >> has likely existed for some time and we are just discovering it now. The >> issue affects multiple Pipelines but all affected Pipelines follow the same >> pattern: >> >> Stage 1: 1 job >> Stage 2: 2 jobs >> >> The issue only affects 1 Agent but this is the only Agent we have that is >> capable of running these jobs. The issue never seems to affect Stage 1 but >> what we see is that if Stage 1 completes and then Stage 2 for the same >> Pipeline starts immediately, both jobs fail with the same error message >> about being unable to delete a particular file. >> >> If we rerun Stage 2 a few minutes later, both jobs complete successfully. >> I have reviewed the Agent's log file and there is no additional information >> beyond the same "Unable to delete file" error message shown on the console. >> >> The file is inside GoCD's working directory and the GoCD user has full >> control of the entire directory tree so it should not be a permissions >> issue on the file. The file is a normal file, not a symlink that could lead >> outside the working directory to somewhere GoCD does not have access. >> >> How can we get additional information about why GoCD is failing to clean >> the working directory so that we can resolve the issue? >> >> At the moment we are working around the issue by manually re-running >> failed Stages but this is obviously far from ideal. >> >> Any insight here would be appreciated. >> >> Thank you, >> Jason >> >> -- >> You received this message because you are subscribed to the Google Groups >> "go-cd" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to go...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/go-cd/b060bcb6-7ac6-484a-8ae9-c1eb7136dcbd%40googlegroups.com >> >> <https://groups.google.com/d/msgid/go-cd/b060bcb6-7ac6-484a-8ae9-c1eb7136dcbd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/ded8e7fa-0f52-41df-9cd3-4aed486231e4%40googlegroups.com.
