I have the same problem, this is not related to “resuming a build on another machine” thing. The problem is that Gradle takes a snapshot of the input file and maps it to the file’s absolute path, this is the root of the issue (as I understand it, of course I might be wrong, you’re the expert) - when you copy your 1st job workspace to the 2nd job workspace (they are on different paths) assuming everything will continue - it has to start all over again as it doesn’t recognize any of the snapshots saved in the copied .gradle directory.
I’ve investigated a bit and found in
org.gradle.api.internal.changedetection.state.DefaultFileSnapshotter
public FileCollectionSnapshot snapshot(FileCollection sourceFiles) {
final Map<String, FileSnapshot> snapshots = new HashMap<String, FileSnapshot>();
final Set<File> theFiles = sourceFiles.getAsFileTree().getFiles();
cacheAccess.useCache("Create file snapshot", new Runnable() {
public void run() {
for (File file : theFiles) {
if (file.isFile()) {
snapshots.put(***file.getAbsolutePath()***, new FileHashSnapshot(hasher.hash(file)));
} else if (file.isDirectory()) {
snapshots.put(***file.getAbsolutePath()***, new DirSnapshot());
} else {
snapshots.put(***file.getAbsolutePath()***, new MissingFileSnapshot());
}
}
}
});
return new FileCollectionSnapshotImpl(snapshots);
}
What I thought was that instead of mapping absolutePath->snapshot, one can use a 2 maps:
absolutePath -> snapshot <- relativePathToMasterBuild.gradle
Since the build process hashs every file anyways, if the build can’t locate the absolute path in the map, try and search for the relative path to the master build.gradle and compare the hash. In theory, this should solve the issue.