Build folder not being cleaned up properly

Summary

At the end of a step, the runner will attempt to clean up the build folder. This is a best effort cleanup and in some cases runners are not able to clean up the build folder. The following are the two most common cases that prevent a runner from cleaning up the build folder:

• The step script creates files that runners do not have permission to remove, for example, set FullControl as Deny for all users.

• The step script is creating orphaned processes that a runner is not able to stop, and some of the files in the build are locked by those orphaned processes. For example, a hosted machine had Gradle daemon (which is not suggested by Gradle), and is set to use daemon for all Gradle builds by: org.gradle.daemon=true. In this case, the processes created by Gradle builds will attach to the existing daemon process, and the runner would not able to stop them at the end of the step.

Any of the above cases will prevent the runner from cleaning up the build folder, and will cause the step to fail with an error informing you to check the runner logs and manually clean up the build folder in the host machine. Any following steps that are scheduled to run on this runner will also cause an error because the build folder was not cleaned up properly.

Solution

You need to contact the admin who has access to the runner and check the runner logs to find out which files are preventing the runner from cleaning up the build folder.

For files that have permissions to prevent runners from removing them, the admin needs to fix the permissions for those files, and then remove the build folder and restart runner.

For files that are locked by orphaned processes, the admin needs to find out the process that locked the files, and kill the process. Then remove the build folder and restart runner.

For either of the above solutions, you need to revisit the step script and the current settings for the host machine which will ensure the step won’t lock the build folder next time you run the step, or you will have to do the manual clean up in host machine again. In the case of Gradle daemon, you can add the --no-daemon option in the Gradle build, and it will prevent any child processes attached to the Gradle daemon.