You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2013/08/28 20:58:56 UTC
[jira] [Updated] (LUCENE-5190) Consistent failure of
TestCheckIndex.testLuceneConstantVersion in jenkins trunk clover build
[ https://issues.apache.org/jira/browse/LUCENE-5190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-5190:
----------------------------------
Attachment: LUCENE-5190.patch
This should fix the bug. This only affects clover builds because the following:
- The hourly Jenkins builds don't change the version string, because artifacts are not archived, Javadocs are also not archived (its just heavy testing)
- The nightly Artifact builds change the version to contain the Jenkins Build Timestamp/Build Number. But when building nightly artifacts we don't run tests, so this is not triggered
- The Clover builds run tests, but they have to change the build number like the nightly artifact builds, because the version number is part of the archived artifacts (in that case the Clover HTML pages). So those should contain (like Javadocs) a build number.
We should change this to not only allow "-SNAPSHOT", but instead allow any version that is equal to expected build version or has anything starting with "-" appended.
This would allow others also to build and run artifacts with customized versions, like "Lucene 4.5.0-dfsg-ubuntu1" (for the Debian guys among us).
The patch changes the assert to allow this.
> Consistent failure of TestCheckIndex.testLuceneConstantVersion in jenkins trunk clover build
> --------------------------------------------------------------------------------------------
>
> Key: LUCENE-5190
> URL: https://issues.apache.org/jira/browse/LUCENE-5190
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Uwe Schindler
> Attachments: LUCENE-5190.patch
>
>
> I'm out of the loop on how clover is run, and how the build system sets up th version params, but looking at the coverage reports i noticed that the trunk clover build seems to have been failing consistently for a while -- some sporadic test failures, but one consistent failure smells like it has to do with a build configuration problem...
> {noformat}
> java.lang.AssertionError: Invalid version: 5.0-2013-08-11_15-22-48
> at __randomizedtesting.SeedInfo.seed([648EC34D8642C547:A7103483A05D2588]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.apache.lucene.index.TestCheckIndex.__CLR3_1_10l79zdz2ior(TestCheckIndex.java:132)
> at org.apache.lucene.index.TestCheckIndex.testLuceneConstantVersion(TestCheckIndex.java:118)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org