On 21 Feb 2014, at 6:02 pm, Joachim Nilsson <jocce.nils...@gmail.com> wrote:

> Hi, I ran into a tricky part of the code that I would like some hints with.
> Background: I am investigating how to make it possible to make incremental 
> builds after a rename or move of the rootDir (normal for incremental builds 
> in CI servers running many executors on different slaves).
> 
> The first part was  fairly easy to solve, in a not so pretty way, but with 
> minimal changes.
> Now I can read the task history even after a move of directories.
> 
> My solution for the first part was to use the incoming task in 
> CacheBackedTaskHistoryRepository to get the project root dir and then strip 
> that part from the path in the binary file just before serializing. Changing 
> the internal representation to non absolute will have way too big impact for 
> me to grasp so I figured small change (a new boolan before the path) in the 
> binary format was better.
> 
>             public void write(Encoder encoder, LazyTaskExecution execution) 
> throws Exception {
>                 ...
>                 encoder.writeInt(execution.getOutputFiles().size());
>                 for (String outputFile : execution.getOutputFiles()) {
>                     if (canBeConvertedFromAbsolutePath(outputFile)){
>                         encoder.writeBoolean(true);
>                         
> encoder.writeString(convertFromAbsolutePath(outputFile));
>                     }else{
>                         encoder.writeBoolean(false);
>                         encoder.writeString(outputFile);
>                     }
>                 }
>                 ...
>             }
> 
> However, it was not done yet. Now I face that the 
> CacheBackedFileSnapshotRepository is also involved in setting the UP-TO-DATE 
> flag to false since it compares output files directly between runs. And this 
> time the whole FileCollectionSnapshot is stored so my minimal change attempt 
> will fail.
> 
> Any suggestions for solving the CacheBackedFileSnapshotRepository? 
> Here, the whole object is serialized and in the serializer, there is no 
> access to Task, Project or Gradle. Replacing the object with relative file 
> references would probably fail the serialization since it uses File.exists 
> for each file.

I would use the cache base directory as the base directory, in both 
CacheBackedFileSnapshotRepository and CacheBackedFileSnapshotRepository. It can 
be queried from TaskArtifactStateCacheAccess, but you’ll have to add a getter 
on it to expose the cache base dir.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply via email to