[ 
https://issues.apache.org/jira/browse/SOLR-15603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405714#comment-17405714
 ] 

Dawid Weiss commented on SOLR-15603:
------------------------------------

I am really curious which tasks you have in mind and looking forward to seeing 
the patch. I think most of the tasks currently use inputs/outputs properly so 
their up-to-date checks work fine. Task output caching is something I've always 
been reluctant about because it allows a small possibility of the build outputs 
being not identical between runs (depending on whether you fetch things from 
cache or not). But I'd love to be proven wrong.

A much more ambitious niche is in how to implement git-versioned task outputs. 
We do have generated code that can take a *long* time to generate (and requires 
vast amounts of resources). The outputs of these tasks are currently stored in 
git and versioned; they're also subject to checksum-checks against their source 
inputs so that if the input is out of sync with the output, the build fails and 
requires regeneration. Implementing this has proven to be *very* complex in 
gradle. I wonder if there is an easier solution to this (the build cache is not 
an option here - the outputs have to be versioned in git). This part implements 
the logic I mentioned above:

https://github.com/apache/lucene/tree/main/gradle/generation
https://github.com/apache/lucene/blob/main/gradle/generation/regenerate.gradle#L81-L104


> Activate Gradle build cache
> ---------------------------
>
>                 Key: SOLR-15603
>                 URL: https://issues.apache.org/jira/browse/SOLR-15603
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Alexis Tual
>            Assignee: Dawid Weiss
>            Priority: Minor
>
> Activate Gradle build cache to avoid re-executing cacheable tasks.
> Make as well some custom tasks cacheable, this effort can be quite large 
> depending on build complexity, so this Jira issue will cover only the 
> straightforward fixes.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to