[
https://issues.apache.org/jira/browse/SOLR-15603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17406753#comment-17406753
]
Dawid Weiss commented on SOLR-15603:
------------------------------------
Where is that pull request you mentioned? I don't see it.
bq. the most costly task is solr:core:test, it takes advantage of up-to-date
checks and local cache if the tests.seed property is set to a fixed value.
The point of randomized testing is that this property is actually changing. We
do want folks (and CI) to run with different randomness as it help discover
bugs and component incompatibilities. So making tests cacheable goes against
what we're trying to achieve here (I understand your point of view though).
Absolute paths (or are they URIs?) in system properties are there because java
security policy file uses these:
{code}
permission java.io.FilePermission "${common.dir}${/}-", "read";
permission java.io.FilePermission "${common-solr.dir}${/}-", "read";
{code}
I'm not sure if you can use relative paths here (maybe you can, I didn't
check). In any case, there are more varying system properties selected
depending on the randomization seed - the locale, default encoding, default
assertion state, security manager, etc. Which brings us back to my first point
above.
bq. My advice here would be to try avoiding applying those properties to all
tests from all projects and then maybe try to fix those relative path issues.
I think this works as intended, actually. Yes, it's not cacheable, but it's
serving the need it was written for (randomize jvm properties and run tests
under very different configurations).
bq. checkBrokenLinks, renderJavadoc, renderSiteJavadoc,
buildLocalJavadocLinksSite, buildSite, prepareLocalJavadocLinksSiteSources,
prepareSiteSources tasks were not cacheable and quite costly, the PR fixes it
but solr:solr-ref-guide:jrubyPrepare is still executed needlessly
(dowloading/installing gems)
Can't see the PR? Thank you for the fixes - I'm looking forward to fixing these!
bq. Regarding the specific issue you're facing with generated code, I didn't
see it in solr build, you're probably refering to lucene build ? (which I
haven't checked yet).
Yes, it's in Lucene. I provided two links in my comment - that's where the
relevant code is.
On another matter, I filed a bug with gradle's antlr plugin recently -
https://github.com/gradle/gradle/issues/18134 - it'd be great to have a fix for
it since right now the AntlrTask is pretty much unusable outside of the
convention source set imposed by the plugin. Thank you!
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
