How to clean a subproject's temporary directory, immediately after executing one of its tasks?

Old Forum Archive
1

Question…

I have a copy task, which is unzipping and copying an archive dependency (which gradle was nice enough to download!).

task explodeDependencies(type: Copy, dependsOn: configurations.nativesdk) {
    configurations.nativesdk.filter { it.toString().endsWith('.zip') }.each {
        from (zipTree(it))
    }
    into "${rootProject.getProjectDir()}/sdks"
}

What is the cleanest way to delete the ‘buildDir/tmp’ directory which is produced by the ‘zipTree()’ method?

Is there any way to do this without causing the ‘explodeDependencies’ task to unzip the archives again? I tested deleting this directory, after the ‘explodeDependencies’ task completed. The task has to unzip the archives again, in order to determine that the inputs haven’t changed.

Some background…

I’m migrating our old build to use Jenkins + Git + Gradle + Artifactory (which is awesome compared to our old process…let me just say). So, my gradle build is trying to wrap the old build commands.

However, our old build can’t really be considered incremental. Therefore, I require a git clean at the very beginning of the process. Either that, or I have to re-clone, which would be even more painful.

Therefore, I’m using the Jenkins Git plugin’s “clean” feature, which occurs before I can run any build task. The command “git clean -xdf” fails, due to a MAX_PATH issue in msysgit (e.g. only on windows). This comes from the previous gradle task, run in the previous build workspace, which produces a really long path for extracting the archive, in the temp directory.

2

Hmm. I guess that I was over-thinking this issue. I worked around it by adding the ‘base’ plugin, in order to get the ‘clean’ task configuration. Then, I configured the Jenkins job to call the tasks in a specific order, such that the equivalent command would be:

gradlew oldBuildScripts:explodeDependencies oldBuildScripts:clean oldBuildScripts:build

I thought that the ‘explodeDependencies’ task was being executed, again, since the ‘build’ task depending on it. But, somehow this worked in my last CI build, so I guess I was wrong… :slight_smile: