Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5393

Jenkins falsely fails builds due to aggressive up-to-date check on junit artifacts

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: junit-plugin
    • Labels:
      None
    • Environment:
      RedHat Linux VMware
    • Similar Issues:

      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

            Activity

            Hide
            ebann ebann added a comment -

            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.

            Show
            ebann ebann added a comment - 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.
            Hide
            kutzi 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.

            Show
            kutzi 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.
            Hide
            nirro 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.

            Show
            nirro 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.
            Hide
            revoltn 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."); + }
            Show
            revoltn 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."); + }
            Hide
            carlosgarcia 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.

            Show
            carlosgarcia 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                carltonb carltonb
              • Votes:
                14 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated: