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

Master and slave in different timezone produce unexpected behaviour

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Trivial
    • Resolution: Fixed
    • clearcase-plugin
    • None
    • Platform: PC, OS: Windows XP

    Description

      If master is in the time zone that is behind the slave machine. and the time
      difference is more than twice than SCM polling frequency, one file version is
      included in more than one build. If there is only one checkin in the deration
      same build is getting build more than once.

      I think it will show unusual behaviour if master time zone is ahead of slave.
      In this it may skip few of the file while showing the change list

      Attachments

        Activity

          kajays kajays added a comment -

          I think if we manage to do following two things the problem can be solved

          1) add the slave time difference while polling clearcase.
          2) poll at the host where the actual build is being performed master.

          kajays kajays added a comment - I think if we manage to do following two things the problem can be solved 1) add the slave time difference while polling clearcase. 2) poll at the host where the actual build is being performed master.
          redsolo redsolo added a comment -

          Reassinging

          redsolo redsolo added a comment - Reassinging
          abayer Andrew Bayer added a comment -

          I believe the underlying problem here is that the previous build time is taken
          straight from the master and used in the cleartool lshistory arguments. So, for
          example, in my particular case, I've got the master in PST and the slave in EST,
          so if the last build ran at 1pm PST on 2/20/2009, the ct lshistory -since
          argument on the slave comes out as "20-feb.13:00:00". There's actually a couple
          things wrong with that - it's not smart to not have the year there, and
          lshistory accepts UTC timezone information in its dates. So
          "20-feb-09.13:00:00UTC-0800" would be a valid value, and would be the correct
          value for the last build time, regardless of what the timezone we're running the
          lshistory in is.

          I'm compiling a local build of clearcase.hpi now, with a change to ClearToolExec
          to fit this. I'll test it out and update here.

          abayer Andrew Bayer added a comment - I believe the underlying problem here is that the previous build time is taken straight from the master and used in the cleartool lshistory arguments. So, for example, in my particular case, I've got the master in PST and the slave in EST, so if the last build ran at 1pm PST on 2/20/2009, the ct lshistory -since argument on the slave comes out as "20-feb.13:00:00". There's actually a couple things wrong with that - it's not smart to not have the year there, and lshistory accepts UTC timezone information in its dates. So "20-feb-09.13:00:00UTC-0800" would be a valid value, and would be the correct value for the last build time, regardless of what the timezone we're running the lshistory in is. I'm compiling a local build of clearcase.hpi now, with a change to ClearToolExec to fit this. I'll test it out and update here.
          abayer Andrew Bayer added a comment -

          Created an attachment (id=576)
          Diffs to ClearToolExec.java and ClearToolExecTest.java to use UTC timezone and year in lshistory -since argument

          abayer Andrew Bayer added a comment - Created an attachment (id=576) Diffs to ClearToolExec.java and ClearToolExecTest.java to use UTC timezone and year in lshistory -since argument
          abayer Andrew Bayer added a comment -

          Hi again -

          Yup, tested it out and it worked like a charm. The only problem I ran into was
          that ClearToolExecTest's lshistory test was comparing against a static string,
          so I had to change ClearToolExecTest to use the same SimpleDateFormat/UTC
          timezone behavior.

          I've never actually submitted anything to an OSS project before, so I'm just
          going to attach my diffs and wait for y'all to review this and/or let me know if
          you want me to commit it. =)

          abayer Andrew Bayer added a comment - Hi again - Yup, tested it out and it worked like a charm. The only problem I ran into was that ClearToolExecTest's lshistory test was comparing against a static string, so I had to change ClearToolExecTest to use the same SimpleDateFormat/UTC timezone behavior. I've never actually submitted anything to an OSS project before, so I'm just going to attach my diffs and wait for y'all to review this and/or let me know if you want me to commit it. =)
          sunfire sunfire added a comment -

          Patch applied.
          Thanks for the fix!

          sunfire sunfire added a comment - Patch applied. Thanks for the fix!

          Code changed in hudson
          User: : sunfire
          Path:
          trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/ClearToolExec.java
          trunk/hudson/plugins/clearcase/src/test/java/hudson/plugins/clearcase/ClearToolExecTest.java
          http://fisheye4.cenqua.com/changelog/hudson/?cs=15764
          Log:
          JENKINS-2493 Thanks Ajay KUMAR for the patch

          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : sunfire Path: trunk/hudson/plugins/clearcase/src/main/java/hudson/plugins/clearcase/ClearToolExec.java trunk/hudson/plugins/clearcase/src/test/java/hudson/plugins/clearcase/ClearToolExecTest.java http://fisheye4.cenqua.com/changelog/hudson/?cs=15764 Log: JENKINS-2493 Thanks Ajay KUMAR for the patch
          abayer Andrew Bayer added a comment -

          Verified as fixed.

          abayer Andrew Bayer added a comment - Verified as fixed.

          People

            sunfire sunfire
            kajays kajays
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: