[
https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183092#comment-17183092
]
Uwe Schindler commented on LUCENE-9474:
---------------------------------------
Hi,
I wanted to give here a short overview what I have did and why:
1. Policeman Jenkins is already working (almost) fine. ASF Jenkins will be
changed today/tomorrow (depending on time). I started with Policeman, because
of a simpler job structure and more required features (JVM randomization, 3+1
operating systems)
2. The JVM randomization have to be somehow "backwards compatible", so I can
use the same scripts for Ant (8.x) and Gradle (master). If we want to change
system property names or Environment variables pointing to JDK Home dir and
Test JVM args, we should delay this a bit. If we change this, I would want to
make the Ant build also fully environment variables conformat, too. The changes
I made were very minimal:
- RUNTIME_JAVA_HOME is now configured by Jenkins using the Environment Setter
Plugin, so I don't need to pass any extra sysprops. On Master builds, it passes
the Env VAR as is, on Ant builds it copies it also to JAVA_HOME.
- TEST_JVM_ARGS was an environment variable already available in my Jenkins
infrastructure and with Ant this was passed down using a system property
(because of lack of environment support in Ant). I just changed the Gradle
build to also consume this environment variable (in addition to
RUNTIME_JAVA_HOME). Patch is simple:
https://github.com/apache/lucene-solr/commit/79f3a1783f511a7f6d7468bc501dec8ac1e29abf
This change allows to have a common Jenkins config: The default Java version is
fixed to JDK-11-latest (also on ASF) and the 2 env vars are populated for
randomized builds. If those are missing, Gradle will use Java 11, with default
tiered hotspot argument.
3. I added a missing property, because {{-Dtests.badapples}} was missing in the
Gradle build:
https://github.com/apache/lucene-solr/commit/5c2e96b5856f8c0471a2b24d2e9488b03f5f8770
4. I had to remove this warning:
https://github.com/apache/lucene-solr/commit/59736814b65c20357f89db65c8dd670fc8dd4d35
(this maybe serves a separate issue, but this causes fails on newer JDKs).
IMHO, the {{-Xlint:path}} is fine, [~erickerickson]. This warning is more a
configuration issue around classpath (empty entries in classpath are
discouraged in newer JDK versions). This does not affect source code, so I
remove it from the list of warnings. To fix it completely, the classpath and
resources folders need to be reinvestigated in Gradle (looks like Javac
complains, when there's only an empty/missing resources folder). In short: Not
urgent, I don't care about that warning
5. The {{tests.haltonfailure}} was added back, as it was heavily used by
Jenkins. See comments before. You may use {{gradlew --continue check}}, but the
big difference is, that Jenkins want to differentiate between "build passed,
but test failures" vs. "build did not pass due to compile failure,
verifications". haltonfailure just recondigures (like in ant) that the test
runner does not exit the whole build with non-success exit code. Jenkins does
not rely on exit code, it monitors test result xml files.
6. I made the external system tools like python2, python3, perl configureable.
This is important for windows nodes, as those tools are not part of OS:
https://github.com/apache/lucene-solr/commit/494a8a8e04b88f8b4ca8ce1958580ede5ecba538
(that's a non invasive change). Please keep names of system properties because
of Ant compatibility!
7. The most complicated change was the version numbering. Actually the change
is not large:
- the version number is anyways passed down to all subprojects, so there's only
one place to define the product version of lucene/solr: root's build. gradle
- Jenkins jobs should be easy configure, without hardcoding the main version
numbers into the build scripts (in short: no "9.0.0" anywhere in the jenkins
config, should be fully dynamic from build file). The only thing that we want
to change is the suffix, e.g. 9.0.0-SNAPSHOT => 9.0.0-jenkins12345
(jenkins12345 is the build number). This allows to also upload those artifacts
to external server (we are planning to do this, for refguide [~ctargett]
already started with that).
-
https://github.com/apache/lucene-solr/commit/ee6cf4c418af8cdc5b10e258df6d77d8a05ffa1f
only splits the top-level version number info version and version.suffix.
Jenkins is only interested on "version.suffix". By setting a system property
for artifact builds, we can just set the jenkins build number as suffix,
instead of SNAPSHOT. It's not more. The discussion started about numbering of
release versions is separate from that. The above change only handles it in
same way like lucene/version.properties (loaded by ant and modified by release
manager).
> Change Jenkins jobs to use Gradle for trunk
> -------------------------------------------
>
> Key: LUCENE-9474
> URL: https://issues.apache.org/jira/browse/LUCENE-9474
> Project: Lucene - Core
> Issue Type: Test
> Components: general/build
> Reporter: Erick Erickson
> Assignee: Uwe Schindler
> Priority: Major
>
> I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies
> for the confusion.
> Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this
> up Real Soon Now.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
