Incremental build state should be decoupled from workspace location

Old Forum
1

Currently gradle considers absolute paths when resolving incremental build state. The result of this is that a workspace can’t be copied to a new location and have an incremental build work the same as in the prior workspace location.

This creates issue with regard to setting up build pipelines in a CI server where you’d like to clone a workspace from a prior build (or copy build artifacts from a prior build workspace into the new build workspace) and NOT have targets rebuilt (something of a cornerstone principle when it comes to constructing build pipelines).

Regardless of the build pipeline / CI issues, however, this just seems like a design flaw… workspace locations should be decoupled from what gradle is doing within that workspace.

In the example below, I would suggest that the “gradle build” in the “test2” workspace (copied from a just completed build in the “test” workspace) should show all tasks as being UP-TO-DATE.

$ mkdir test; cd test
$ gradle init --type java-library
:wrapper
:init
  BUILD SUCCESSFUL
  Total time: 4.338 secs
  $ gradle build
:compileJava
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
:check
:build
  BUILD SUCCESSFUL
  Total time: 10.106 secs
  $ gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build UP-TO-DATE
  BUILD SUCCESSFUL
  Total time: 5.342 secs
  $ cd ..
$ cp -r test test2
$ cd test2
  $ gradle build
:compileJava
:processResources UP-TO-DATE
:classes
:jar
:assemble
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
:check
:build
  BUILD SUCCESSFUL
  Total time: 8.812 secs
2

There’s a discussion on this occurring on the developer list: http://gradle.1045684.n5.nabble.com/task-artifact-cache-storing-absolute-paths-preventing-CI-workspace-reuse-td5712284.html

3

The end result of the discussion linked to above is that we are willing to make the change to how the task artifact cache stores file paths right now to make them relative. The quickest way to get this in would be to contribute it if you’re willing. Otherwise, it’s unscheduled.

However, portability of the task artifact cache is still not “supported”. There are some cases where the change proposed here is not enough, and it’s not something that we test for. This may change in the future, but no immediate plans. See the email thread for more info.

4

One thing to remember when implementing this is that the jobs may run on different slaves, so any dependencies to other jobs output would fail.

5

Did anything ever become of this? Are there any workarounds?

Allowing workspaces to be copied from one place to another while keeping their state seems like a very easy and efficient way of achieving a halfway decent build pipeline…

6

Hi David,

Nothing has changed since the last activity on this thread, other than putting a “Global Cache” item on our [roadmap](http://www.gradle.org/roadmap). That’s not quite the same thing, but it would solve this problem.