Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
RedHat Linux VMware
Description
I'm getting this error at the end of a build in Hudson that should have been successful. I don't know why this age check is failing but I would be satisfied if I could simply disable the check.
Archiving artifacts
Recording test results
Test reports were found but none of them are new. Did tests run?
For example, /opt/hudson-workspace/workspace/project/target/test/reports/unittest/Ant suite/Ant test.xml is 3 min 13 sec old
These files are, without question, up to date and generated only by the current built.
Here are my questions:
1: The comparison is between the date of the file and... what other thing? What do "new" and "old" mean in this context?
2: How can I disable or deceive this comparison? It's completely unwanted and unnecessary.
I know there was a bug for this in earlier versions of Hudson, but apparently the error message was the only thing changed.
The problem still occurs in 1.341. As for the environment, these are RedHat Linux virtual machines, and the dates on the system are synchronized to within 1 second. I cannot understand why Hudson thinks these files are too old.
Attachments
Issue Links
- duplicates
-
-
- In Progress
-
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
-
JENKINS-10035 Not updated test reports reported as error
-
- Open
-
-
-
- Closed
-
Activity
kutzi
added a comment - Regarding Kohsuke's comment from 15/Jun/10: I'd say that not doing a clean build and relying on some 'magic' timestamp comparison to calculate the test results, is asking for errors.
I agree with others that this feature should be configurable - and ideally off by default, but that's probably not possible for backwards compatibility.
kutzi
added a comment - Regarding Kohsuke's comment from 15/Jun/10: I'd say that not doing a clean build and relying on some 'magic' timestamp comparison to calculate the test results, is asking for errors.
I agree with others that this feature should be configurable - and ideally off by default, but that's probably not possible for backwards compatibility. 
Stanislav Tyurikov
added a comment - This is a stopper for some cases of build execution time optimization. I even can't imagine the reasons why this feature exists.
Stanislav Tyurikov
added a comment - This is a stopper for some cases of build execution time optimization. I even can't imagine the reasons why this feature exists. 
Kent Bolton
added a comment - Looks like the magic number is 1000 miliseconds. Code below in a patch here: http://git.eclipse.org/c/hudson/org.eclipse.hudson.core.git/commit?id=97587dde35e862fabbd8b5b4b0136a786cfcff37 .
This is an issue when using VMs where time can drift quite quickly. Would be good to disable this test, or to be able to change the magic number of seconds in configuration.
@@ -151,21 +144,22 @@ public final class TestResult extends MetaTabulatedResult {
}
}
- if(!parsed) {
+ if (!parsed) {
long localTime = System.currentTimeMillis(); - if(localTime < buildTime-1000) /margin/
- // build time is in the the future. clock on this slave must be running behind
+ if (localTime < buildTime - 1000) /margin/ // build time is in the the future. clock on this slave must be running behind
+ { throw new AbortException( - "Clock on this slave is out of sync with the master, and therefore \n" + - "I can't figure out what test results are new and what are old.\n" + - "Please keep the slave clock in sync with the master."); + "Clock on this slave is out of sync with the master, and therefore \n" + + "I can't figure out what test results are new and what are old.\n" + + "Please keep the slave clock in sync with the master."); + }
Kent Bolton
added a comment - Looks like the magic number is 1000 miliseconds. Code below in a patch here: http://git.eclipse.org/c/hudson/org.eclipse.hudson.core.git/commit?id=97587dde35e862fabbd8b5b4b0136a786cfcff37 .
This is an issue when using VMs where time can drift quite quickly. Would be good to disable this test, or to be able to change the magic number of seconds in configuration.
@@ -151,21 +144,22 @@ public final class TestResult extends MetaTabulatedResult {
}
}
if(!parsed) {
+ if (!parsed) {
long localTime = System.currentTimeMillis();
if(localTime < buildTime-1000) / margin /
// build time is in the the future. clock on this slave must be running behind
+ if (localTime < buildTime - 1000) / margin / // build time is in the the future. clock on this slave must be running behind
+
{
throw new AbortException(
- "Clock on this slave is out of sync with the master, and therefore \n" +
- "I can't figure out what test results are new and what are old.\n" +
- "Please keep the slave clock in sync with the master.");
+ "Clock on this slave is out of sync with the master, and therefore \n"
+ + "I can't figure out what test results are new and what are old.\n"
+ + "Please keep the slave clock in sync with the master.");
+ }
Carlos Garcia
added a comment - I have a similar problem. Even though my clocks are in sync (agents and master), Jenkins complains about them being out of sync.
I agree with you, making this "magic number" of 1000 configurable, or even disabling this unnecessary check, is necessary. Given that this is a 9-year-old bug I don't expect this to be fixed; I'll try to modify this behaviour myself and build Jenkins.
Carlos Garcia
added a comment - I have a similar problem. Even though my clocks are in sync (agents and master), Jenkins complains about them being out of sync.
I agree with you, making this "magic number" of 1000 configurable, or even disabling this unnecessary check, is necessary. Given that this is a 9-year-old bug I don't expect this to be fixed; I'll try to modify this behaviour myself and build Jenkins. 
Related to 6268.
Aggressive time check should be an option.
In my case Junit xml files are retrieved in other jobs artifacts, i just want to regroup and parse all tests results in a single job.