• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • Hudson 1.355

      It seems to me that the graphical representation of the build time trend is not in the place it should be (see attached screenshot).

        1. ScreenShotWithTwoDataPoints.jpg
          ScreenShotWithTwoDataPoints.jpg
          61 kB
        2. TimelineMissingDataWrongHour.jpg
          TimelineMissingDataWrongHour.jpg
          120 kB
        3. JENKINS-6439-2.patch
          0.7 kB
        4. JENKINS-6439.patch
          2 kB
        5. Timeline_NewBuilds.jpg
          Timeline_NewBuilds.jpg
          210 kB
        6. BuildTimeTrend.jpg
          BuildTimeTrend.jpg
          373 kB

          [JENKINS-6439] Timeline on BuildTimeTrend page does not work

          torbent added a comment -

          I'll comment on that

          Hudson version is 1.360. The job used in the test had 25 builds from May 13th to today, with build numbers in the 900's. I didn't think to clear the browser caches, but did use Ctrl-F5 to refresh (which usually is just as good?).

          On Windows XP with Internet Explorer 8 I get no timeline, but a script error ala "Object doesn't support this property or method" in line 66, char 1. It's unclear to me which line 66 it means, as there are many scripts being imported/run, but line 66 of the page itself is something like "timeline.urlPrefix ='/adjuncts/etc';"

          On a Ubuntu Linux with Firefox 3.5.7 I get a timeline. It's scrollable within the date range, but there's apparently no data in it; no blue marks.

          torbent added a comment - I'll comment on that Hudson version is 1.360. The job used in the test had 25 builds from May 13th to today, with build numbers in the 900's. I didn't think to clear the browser caches, but did use Ctrl-F5 to refresh (which usually is just as good?). On Windows XP with Internet Explorer 8 I get no timeline, but a script error ala "Object doesn't support this property or method" in line 66, char 1. It's unclear to me which line 66 it means, as there are many scripts being imported/run, but line 66 of the page itself is something like "timeline.urlPrefix ='/adjuncts/etc';" On a Ubuntu Linux with Firefox 3.5.7 I get a timeline. It's scrollable within the date range, but there's apparently no data in it; no blue marks.

          I think it is clear now that it does not work for any of us except mindless
          So I reopen to be sure it is not forgotten.

          Vivien Tintillier added a comment - I think it is clear now that it does not work for any of us except mindless So I reopen to be sure it is not forgotten.

          Alan Harder added a comment -

          Unassigning myself.. I fixed the original problem to make it possible for this to work at all, but there's not enough info to fix whatever else is going wrong, and this feature (that was not added by me, btw) is not useful enough for me to dig further, sorry.

          I did confirm it doesn't work in IE7.. but one last test in 1.358 for a job with 18 builds worked in FF 3.6.3 and Opera 10.53.

          Alan Harder added a comment - Unassigning myself.. I fixed the original problem to make it possible for this to work at all, but there's not enough info to fix whatever else is going wrong, and this feature (that was not added by me, btw) is not useful enough for me to dig further, sorry. I did confirm it doesn't work in IE7.. but one last test in 1.358 for a job with 18 builds worked in FF 3.6.3 and Opera 10.53.

          torbent added a comment -

          I wonder then if there's a way to disable the timeline altogether?
          We have very few non-IE browsers at work, so as long as the timeline doesn't work it's just a waste of screen space ...

          torbent added a comment - I wonder then if there's a way to disable the timeline altogether? We have very few non-IE browsers at work, so as long as the timeline doesn't work it's just a waste of screen space ...

          starfury added a comment - - edited

          A late reply to mindless:
          I've upgraded to 1.360 in the meantime and I have one older job with 10 builds (all before 1.360) where the timeline does not show any builds and I've created a new test job which has now 6 builds (all 1.360) which also does not show any builds (on both FF and Opera as mentioned above).

          One other thing I noticed with the time line when running those test job builds:
          The latest build I ran about half an hour (2010-06-04 15:17 MEST) ago but the time line starts showing and being limited to tomorrow ("Jun 5") about 13:30.
          Maybe this is a hint for tracking down the problem or it probably means nothing.
          (See Screenshot #2)

          starfury added a comment - - edited A late reply to mindless: I've upgraded to 1.360 in the meantime and I have one older job with 10 builds (all before 1.360) where the timeline does not show any builds and I've created a new test job which has now 6 builds (all 1.360) which also does not show any builds (on both FF and Opera as mentioned above). One other thing I noticed with the time line when running those test job builds: The latest build I ran about half an hour (2010-06-04 15:17 MEST) ago but the time line starts showing and being limited to tomorrow ("Jun 5") about 13:30. Maybe this is a hint for tracking down the problem or it probably means nothing. (See Screenshot #2)

          nellyt added a comment -

          Hudson 1.365
          All on windows
          IE shows an empty white timeline rectangle
          Chrome shows a scrollable timeline with no ticks
          Firefox shows a scrollable timeline with no ticks then diverts to a 404 error page and gives numerous (about 20 or 30) firefox/windows popups - The page at <hudson server> says "Syntax error:syntax error"

          Result : I can no longer use Hudson from Firefox.

          nellyt added a comment - Hudson 1.365 All on windows IE shows an empty white timeline rectangle Chrome shows a scrollable timeline with no ticks Firefox shows a scrollable timeline with no ticks then diverts to a 404 error page and gives numerous (about 20 or 30) firefox/windows popups - The page at <hudson server> says "Syntax error:syntax error" Result : I can no longer use Hudson from Firefox.

          Elfe added a comment -

          my timeline also shows tomorrow as current selected view

          also strange is that it does not show any events

          Elfe added a comment - my timeline also shows tomorrow as current selected view also strange is that it does not show any events

          Alan Harder added a comment -

          nellty, I still don't see any problems in timeline view in firefox. Example: http://ci.hudson-labs.org/job/hudson_main_trunk/buildTimeTrend

          Alan Harder added a comment - nellty, I still don't see any problems in timeline view in firefox. Example: http://ci.hudson-labs.org/job/hudson_main_trunk/buildTimeTrend

          glundh added a comment -

          mindless:

          On which container is that one running?

          I, like many others, have tried to getting the Build Time Trend to work in any way possible.

          I have tried Firefox (Linux/Win), Chrome (Linux/Win), IE 8 with a all sorts of various browser locale settings (Just incase it was a date formatting issue).

          I have tried these browsers in combinations with various Hudson-versions, including latest trunk.

          I have tried with winstone and tomcat. I cannot get the trend to work. It is scrollable, but ticks is never visible. I have tried various lengths of build, still no results.

          So know I'm thinking, maybe it only works on JBoss or some other specific container?

          Br
          Gustaf

          glundh added a comment - mindless: On which container is that one running? I, like many others, have tried to getting the Build Time Trend to work in any way possible. I have tried Firefox (Linux/Win), Chrome (Linux/Win), IE 8 with a all sorts of various browser locale settings (Just incase it was a date formatting issue). I have tried these browsers in combinations with various Hudson-versions, including latest trunk. I have tried with winstone and tomcat. I cannot get the trend to work. It is scrollable, but ticks is never visible. I have tried various lengths of build, still no results. So know I'm thinking, maybe it only works on JBoss or some other specific container? Br Gustaf

          The timeline works for me with the URL provided by mindless, on both Chrome & FF. But it still does not work on my own hudson install.
          The only thing that is different is the timezone: I have "var tz=1", whereas the hudsonlabbs one has "var tz=-5".

          mindless, any idea if it could be the cause?

          Vivien Tintillier added a comment - The timeline works for me with the URL provided by mindless, on both Chrome & FF. But it still does not work on my own hudson install. The only thing that is different is the timezone: I have "var tz=1", whereas the hudsonlabbs one has "var tz=-5". mindless, any idea if it could be the cause?

          Jose Sa added a comment -

          Running 1.377 on both WinXP and Solaris10, with default container Winstone:
          Timeline remains the same

          • Completely Blank on IE8
          • Scrollable timeline on Firefox and Chrome, but no events shown

          Jose Sa added a comment - Running 1.377 on both WinXP and Solaris10, with default container Winstone: Timeline remains the same Completely Blank on IE8 Scrollable timeline on Firefox and Chrome, but no events shown

          mfilteau added a comment -

          Running 1.374-1.377, timeline is exactly as shown on the first screenshot on IE8.

          I get the following JScript error:

          Object doesn't support this property or method

          buildTimeTrend, line 103, character 5:

          window.addEventListener('load', function() {
          var tl_el = document.getElementById("tl");
          var eventSource1 = new Timeline.DefaultEventSource();
          eventSource1.loaded = {};
          var interval = 24*60*60*1000;
          eventSource1.ensureVisible = function(band) {
          // make sure all data are loaded for the portion visible in the band
          // ('status').innerHTML = "min="band.getMinDate()" max="+band.getMaxDate();
          var min = Math.floor(band.getMinDate().getTime()/interval);
          var max = Math.ceil(band.getMaxDate().getTime()/interval);
          for (var i=min; i<=max; i++) {
          if (!this.loaded[i]) {
          this.loaded[i] = true;
          new Ajax.Request("timeline/data",{
          method:"POST",
          parameters:

          {min: i*interval, max:(i+1)*interval}

          ,
          onSuccess: function(t) {
          try

          { eventSource1.loadJSON(eval('('+t.responseText+')'),'.'); }

          catch (e)

          { alert(e); }

          }
          });
          }
          }
          };
          ....

          mfilteau added a comment - Running 1.374-1.377, timeline is exactly as shown on the first screenshot on IE8. I get the following JScript error: Object doesn't support this property or method buildTimeTrend, line 103, character 5: window.addEventListener('load', function() { var tl_el = document.getElementById("tl"); var eventSource1 = new Timeline.DefaultEventSource(); eventSource1.loaded = {}; var interval = 24*60*60*1000; eventSource1.ensureVisible = function(band) { // make sure all data are loaded for the portion visible in the band // ('status').innerHTML = "min=" band.getMinDate() " max="+band.getMaxDate(); var min = Math.floor(band.getMinDate().getTime()/interval); var max = Math.ceil(band.getMaxDate().getTime()/interval); for (var i=min; i<=max; i++) { if (!this.loaded [i] ) { this.loaded [i] = true; new Ajax.Request("timeline/data",{ method:"POST", parameters: {min: i*interval, max:(i+1)*interval} , onSuccess: function(t) { try { eventSource1.loadJSON(eval('('+t.responseText+')'),'.'); } catch (e) { alert(e); } } }); } } }; ....

          Jose Sa added a comment -

          It seems that the timeline is basing on the process of the url http://server/prefix/timeline/data to get the events to show that is returning empty.

          in my case, http://localhost:8080/hudson/timeline/data is returning:

          {"events":[]}

          Jose Sa added a comment - It seems that the timeline is basing on the process of the url http://server/prefix/timeline/data to get the events to show that is returning empty. in my case, http://localhost:8080/hudson/timeline/data is returning: {"events":[]}

          heiko_bihr added a comment -

          Running 1.379 on apache tomcat 6.0.29 on ubuntu with jre-1.6.0_20

          Timeline is shown, but does not contain any markers (as in Timeline_NewBuilds.jpg above).

          There seems to be something weird with the date range, the timeline should display.

          In the page source of the build trend, I can see the following variable definitons:

          theme1.timeline_start = new Date(1282950098000);
          theme1.timeline_stop = new Date(1287010890084);

          This indicates, the timeline should show all events in the range from 06/Jul/10 to 04/Sep/10. But today is 13/Oct/10 and the timeline focuses this date (although it seems to be 4 hours in the future)

          @iosesa: did you just point your browser to the timeline/data url? hudson sends an ajax request to this URL.

          I caputerd all HTTP requests when loading the build trend page, and there is one request that should load the event data to display in the timeline. This is the request to the .../timeline/data. It has the parameters

          min=1287705600000&max=1287792000000

          This is 5/Sep/10 for min and 6/Sep/10 for max (this is not part of the range of the timeline (see above)).

          When replaying this request (using firefox' live HTTP headers plugin), I get the same response as josesa:

          {"events":[]}

          But if I set the parameters to

          min=0&max=1287792000000

          I get back a list of all build events that are recorded in hudson (we keep only the last 50 builds):

          {"events":[

          {"classname":"event-blue ","color":"#4F6F90","description":"","durationEvent":false,"end":"Wed Oct 13 01:01:35 CEST 2010","link":"/hudson/job/project/117/","start":"Wed Oct 13 01:01:30 CEST 2010","title":"project #117"}

          ,
          [...]

          {"classname":"event-blue ","color":"#4F6F90","description":"","durationEvent":false,"end":"Sun Aug 29 01:01:55 CEST 2010","link":"/hudson/job/project/68/","start":"Sun Aug 29 01:01:38 CEST 2010","title":"project #68"}

          ]}

          I assume, there is something really wrong, when calculating date offsets for the
          timeline.

          Our hudson runs in timezone UTC+2 (central european summer time), my brwoser (firefox 3.6 runs on a WinXP client, which is in the same timezone).

          heiko_bihr added a comment - Running 1.379 on apache tomcat 6.0.29 on ubuntu with jre-1.6.0_20 Timeline is shown, but does not contain any markers (as in Timeline_NewBuilds.jpg above). There seems to be something weird with the date range, the timeline should display. In the page source of the build trend, I can see the following variable definitons: theme1.timeline_start = new Date(1282950098000); theme1.timeline_stop = new Date(1287010890084); This indicates, the timeline should show all events in the range from 06/Jul/10 to 04/Sep/10. But today is 13/Oct/10 and the timeline focuses this date (although it seems to be 4 hours in the future) @iosesa: did you just point your browser to the timeline/data url? hudson sends an ajax request to this URL. I caputerd all HTTP requests when loading the build trend page, and there is one request that should load the event data to display in the timeline. This is the request to the .../timeline/data. It has the parameters min=1287705600000&max=1287792000000 This is 5/Sep/10 for min and 6/Sep/10 for max (this is not part of the range of the timeline (see above)). When replaying this request (using firefox' live HTTP headers plugin), I get the same response as josesa: {"events":[]} But if I set the parameters to min=0&max=1287792000000 I get back a list of all build events that are recorded in hudson (we keep only the last 50 builds): {"events":[ {"classname":"event-blue ","color":"#4F6F90","description":"","durationEvent":false,"end":"Wed Oct 13 01:01:35 CEST 2010","link":"/hudson/job/project/117/","start":"Wed Oct 13 01:01:30 CEST 2010","title":"project #117"} , [...] {"classname":"event-blue ","color":"#4F6F90","description":"","durationEvent":false,"end":"Sun Aug 29 01:01:55 CEST 2010","link":"/hudson/job/project/68/","start":"Sun Aug 29 01:01:38 CEST 2010","title":"project #68"} ]} I assume, there is something really wrong, when calculating date offsets for the timeline. Our hudson runs in timezone UTC+2 (central european summer time), my brwoser (firefox 3.6 runs on a WinXP client, which is in the same timezone).

          Jose Sa added a comment -

          So where can the parameters min & max be set?
          Is there any configuration file I can use to override this ?

          Jose Sa added a comment - So where can the parameters min & max be set? Is there any configuration file I can use to override this ?

          starfury added a comment -

          Any news? With its JavaScript exceptions (see comment by vtintillier at 22/May/10 03:06 AM) this bug is really annoying.

          starfury added a comment - Any news? With its JavaScript exceptions (see comment by vtintillier at 22/May/10 03:06 AM) this bug is really annoying.

          ggi added a comment -

          Hi,

          I also see in our hudson installation the timeline without the builds.

          I've workaround the problem setting the server timezone configuration to GMT.

          The exact version that I've tested is the 1.377 (the current one in http://ci.hudson-labs.org).

          I hope this info will help to fix this issue, or at least it will be useful to know what are the supported timezones.

          ggi added a comment - Hi, I also see in our hudson installation the timeline without the builds. I've workaround the problem setting the server timezone configuration to GMT. The exact version that I've tested is the 1.377 (the current one in http://ci.hudson-labs.org ). I hope this info will help to fix this issue, or at least it will be useful to know what are the supported timezones.

          Jose Sa added a comment -

          Nice catch.

          I already noticed that when I ran hudson in a Windows server (with GMT Timezone) that I could see the timeline correctly in my Windows Laptop.

          My Solaris Server is running in WET timezone and I never saw anything in my laptop. I forced in the hudson start script to have "export TZ=GMT" and now timeline finally shows something in my laptop.

          Still the timeline centers day in advance by default, but at least now shows something if I scroll a day to the left.

          Jose Sa added a comment - Nice catch. I already noticed that when I ran hudson in a Windows server (with GMT Timezone) that I could see the timeline correctly in my Windows Laptop. My Solaris Server is running in WET timezone and I never saw anything in my laptop. I forced in the hudson start script to have "export TZ=GMT" and now timeline finally shows something in my laptop. Still the timeline centers day in advance by default, but at least now shows something if I scroll a day to the left.

          vcher added a comment -

          It seems that I've found a workaround to fix this issue. When Hudson starts with option -Duser.timezone=GMT+N, all works fine, and on Windows 2k3 timeline shows builds correctly.

          A part of my hudson.xml is below :

          <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Duser.timezone=GMT+6 -jar "%BASE%\hudson.war" --httpPort=8080</arguments>

          vcher added a comment - It seems that I've found a workaround to fix this issue. When Hudson starts with option -Duser.timezone=GMT+N, all works fine, and on Windows 2k3 timeline shows builds correctly. A part of my hudson.xml is below : <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Duser.timezone=GMT+6 -jar "%BASE%\hudson.war" --httpPort=8080</arguments>

          Yes, works for me too with GMT+1.

          But still by default it is one day in the future.

          Vivien Tintillier added a comment - Yes, works for me too with GMT+1. But still by default it is one day in the future.

          I stared into the sources for quite a while and may have found the culprit. Unfortunately I don't have a working build environment to build Jenkins and verify my findings...

          If I understand this code correctly it looks to me as if in org.koshuke.stapler.simile.timeline.TimelineEventList a JsonValueProcessor takes care that the toString()-method gets called for every Date field in org.koshuke.stapler.simile.timeline.Event.

          This is in so far problematic as this may produce output like "Mon Mar 07 15:24:05 CET 2011", while the SIMILE Timeline accepts either one of "May 10 1961 00:00:00 GMT-0600", "Thu, 21 Dec 2000 16:01:07 +0200", and a few others which they do not exactly recommend. All of them have in common that they specify the timezone as offset from GMT.

          This might be the reason why the workarounds people documented earlier work. These workarounds change the output to "Mon Mar 07 15:25:14 GMT+01:00 2011". Which is still different from what is documented for the Timeline widget, though. (http://code.google.com/p/simile-widgets/wiki/Timeline_EventSources)

          Can someone verify this?
          – Matthias

          Matthias Kraft added a comment - I stared into the sources for quite a while and may have found the culprit. Unfortunately I don't have a working build environment to build Jenkins and verify my findings... If I understand this code correctly it looks to me as if in org.koshuke.stapler.simile.timeline.TimelineEventList a JsonValueProcessor takes care that the toString()-method gets called for every Date field in org.koshuke.stapler.simile.timeline.Event. This is in so far problematic as this may produce output like "Mon Mar 07 15:24:05 CET 2011", while the SIMILE Timeline accepts either one of "May 10 1961 00:00:00 GMT-0600", "Thu, 21 Dec 2000 16:01:07 +0200", and a few others which they do not exactly recommend. All of them have in common that they specify the timezone as offset from GMT. This might be the reason why the workarounds people documented earlier work. These workarounds change the output to "Mon Mar 07 15:25:14 GMT+01:00 2011". Which is still different from what is documented for the Timeline widget, though. ( http://code.google.com/p/simile-widgets/wiki/Timeline_EventSources ) Can someone verify this? – Matthias

          Attached a patch against org.koshuke.stapler.simile.timeline.TimelineEventList which fixes the issue that no events are displayed. This makes the workarounds unnecessary.

          It does not address the "default is off by one day" issue. But I have an idea here, too.

          Matthias Kraft added a comment - Attached a patch against org.koshuke.stapler.simile.timeline.TimelineEventList which fixes the issue that no events are displayed. This makes the workarounds unnecessary. It does not address the "default is off by one day" issue. But I have an idea here, too.

          here it is

          Matthias Kraft added a comment - here it is

          Here is a fix for the second issue. This is against core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly. It moves the focus to the last event of the time line.

          Matthias Kraft added a comment - Here is a fix for the second issue. This is against core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly. It moves the focus to the last event of the time line.

          How can I attach the patch against org.koshuke.stapler.simile.timeline.TimelineEventList?

          -Martin

          Martin Bönsch added a comment - How can I attach the patch against org.koshuke.stapler.simile.timeline.TimelineEventList? -Martin

          Hi the GMT+1 "trick" fixed it for me too, (there was Europe/Zuerich) as timezone given as provided by the underlying debian.
          So i changed the /etc/default/jenkins JAGA_ARGS accordingly and added -Duser.timezone=GMT+1

          And now I got have some other problems:
          we have so may builds and jobs that there are several issues now:

          • too many jobs are shown in timeline
          • so chrome sometimes locks up (firefox or ie even worse)
          • page loading speed decreased extremely (~ 1 minute)
          • build timeline graph isnt high enough to show all jobs vertically, it just cuts off after showing 10 (i see there is at least an 11th one but its hard to idntify you only see parts of the letters, so i assume there are a lot more)

          so would you propose to add single issues for every of these?
          cheers philipp

          Philipp Mohrenweiser added a comment - Hi the GMT+1 "trick" fixed it for me too, (there was Europe/Zuerich) as timezone given as provided by the underlying debian. So i changed the /etc/default/jenkins JAGA_ARGS accordingly and added -Duser.timezone=GMT+1 And now I got have some other problems: we have so may builds and jobs that there are several issues now: too many jobs are shown in timeline so chrome sometimes locks up (firefox or ie even worse) page loading speed decreased extremely (~ 1 minute) build timeline graph isnt high enough to show all jobs vertically, it just cuts off after showing 10 (i see there is at least an 11th one but its hard to idntify you only see parts of the letters, so i assume there are a lot more) so would you propose to add single issues for every of these? cheers philipp

          @Martin: Kohsuke recently moved the stapler repository to github. I forked it today, applied the patch for the timezone issue, and opened a pull request.

          @Philipp: For the new issues open up a new bug report, please.

          Matthias Kraft added a comment - @Martin: Kohsuke recently moved the stapler repository to github. I forked it today, applied the patch for the timezone issue, and opened a pull request. @Philipp: For the new issues open up a new bug report, please.

          Also forked the jenkins repo, applied the patch for the off-by-one-day issue, and opened a pull request.

          Matthias Kraft added a comment - Also forked the jenkins repo, applied the patch for the off-by-one-day issue, and opened a pull request.

          Code changed in jenkins
          User: Matthias Kraft
          Path:
          changelog.html
          core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly
          http://jenkins-ci.org/commit/jenkins/f5e29cbca52cdfb75a86cefe7f5dbb9f696c4160
          Log:
          [FIXED JENKINS-6439] Fixed Timeline widget's default view off by one day.

          Second part of the JENKINS-6439 fix.

          Signed-off-by: Matthias Kraft <Matthias.Kraft@softwareag.com>

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Matthias Kraft Path: changelog.html core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly http://jenkins-ci.org/commit/jenkins/f5e29cbca52cdfb75a86cefe7f5dbb9f696c4160 Log: [FIXED JENKINS-6439] Fixed Timeline widget's default view off by one day. Second part of the JENKINS-6439 fix. Signed-off-by: Matthias Kraft <Matthias.Kraft@softwareag.com>

          dogfood added a comment -

          Integrated in jenkins_main_trunk #660
          [FIXED JENKINS-6439] Fixed Timeline widget's default view off by one day.

          Kohsuke Kawaguchi : f5e29cbca52cdfb75a86cefe7f5dbb9f696c4160
          Files :

          • core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #660 [FIXED JENKINS-6439] Fixed Timeline widget's default view off by one day. Kohsuke Kawaguchi : f5e29cbca52cdfb75a86cefe7f5dbb9f696c4160 Files : core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly changelog.html

          The issue is not fixed for me in Jenkins ver. 1.411. There are still no entries at all in the timeline. Only the second part of this issue is fixed (the "Timeline widget's default view off by one day" part).
          Running Jenkins ver. 1.411 on Windows 2003 Server as a service, tested on Firefox 3.6.13 and Safari 5.0.5.
          In which version is this issue supposed to be fixed? Should I reopen this bug or fill in another bug report?

          Christoph Vogtländer added a comment - The issue is not fixed for me in Jenkins ver. 1.411. There are still no entries at all in the timeline. Only the second part of this issue is fixed (the "Timeline widget's default view off by one day" part). Running Jenkins ver. 1.411 on Windows 2003 Server as a service, tested on Firefox 3.6.13 and Safari 5.0.5. In which version is this issue supposed to be fixed? Should I reopen this bug or fill in another bug report?

          Harry G. added a comment - - edited

          Same for me. No entries in the timeline in 1.411 - as in all previous versions.
          Could this still be dependent of the locale resulting in a different time/date format as discussed above?
          Maybe only one of both fixes from Matthias Kraft were integrated?

          Harry G. added a comment - - edited Same for me. No entries in the timeline in 1.411 - as in all previous versions. Could this still be dependent of the locale resulting in a different time/date format as discussed above? Maybe only one of both fixes from Matthias Kraft were integrated?

          Heiko Tappe added a comment -

          And same for me: For all jenkins versions so far I never saw any builds in the timeline (current version(s) 1.410 on Windows, 1.409 on Debian - checked with Firefox, Chrome and Opera, IE9 doesn't show the timeline at all).
          Trying to find the reason for this I had a look at what happens (Firefox 4.0 via firebug).
          Several ajax request are fired to get the data for the timeline. Some of them return JSON data, some of them don't.
          But only ONE - the last - request runs into the "onSuccess" function which in my case never contains any data.
          So I think the question is: why does only one request run into the onSuccess function and not all of them?

          --Heiko

          Heiko Tappe added a comment - And same for me: For all jenkins versions so far I never saw any builds in the timeline (current version(s) 1.410 on Windows, 1.409 on Debian - checked with Firefox, Chrome and Opera, IE9 doesn't show the timeline at all). Trying to find the reason for this I had a look at what happens (Firefox 4.0 via firebug). Several ajax request are fired to get the data for the timeline. Some of them return JSON data, some of them don't. But only ONE - the last - request runs into the "onSuccess" function which in my case never contains any data. So I think the question is: why does only one request run into the onSuccess function and not all of them? --Heiko

          Issue only fixed partly. Still, no entries are shown in the timeline for several users as of Jenkins ver. 1.411

          Christoph Vogtländer added a comment - Issue only fixed partly. Still, no entries are shown in the timeline for several users as of Jenkins ver. 1.411

          I double checked. The fixes were both committed to the repos, but the stapler-adjunct-timeline framework has not yet been updated in Jenkins, as it seems (stapler-adjunct-timeline-1.2.jar is still included).

          – Matthias

          Matthias Kraft added a comment - I double checked. The fixes were both committed to the repos, but the stapler-adjunct-timeline framework has not yet been updated in Jenkins, as it seems (stapler-adjunct-timeline-1.2.jar is still included). – Matthias

          Vivien Tintillier added a comment - - edited

          This has been working for me since last month, not sure which version. It works with 1.408 now at least, not tried 1.411. Please note that I have '-Duser.timezone=GMT+1' in the java arguments.

          Tested with firefox 4 (and I think I tested with 3.6 and it worked), chrome 11.

          It does not work with ie 8 however, still javascript error:

          Webpage error details

          User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E)
          Timestamp: Fri, 13 May 2011 11:27:17 UTC

          Message: Object doesn't support this property or method
          Line: 16
          Char: 5
          Code: 0
          URI: http://dewdfth04154p:8080/builds

          Vivien Tintillier added a comment - - edited This has been working for me since last month, not sure which version. It works with 1.408 now at least, not tried 1.411. Please note that I have '-Duser.timezone=GMT+1' in the java arguments. Tested with firefox 4 (and I think I tested with 3.6 and it worked), chrome 11. It does not work with ie 8 however, still javascript error: Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E) Timestamp: Fri, 13 May 2011 11:27:17 UTC Message: Object doesn't support this property or method Line: 16 Char: 5 Code: 0 URI: http://dewdfth04154p:8080/builds

          Olaf Lenz added a comment -

          Same problem here, using 1.414.

          Olaf Lenz added a comment - Same problem here, using 1.414.

          Code changed in jenkins
          User: Ulli Hafner
          Path:
          changelog.html
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/6aa47505897a1f5b04336fbfc0cff65938417cae
          Log:
          [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ulli Hafner Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/6aa47505897a1f5b04336fbfc0cff65938417cae Log: [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #868
          [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          Ulli Hafner : 6aa47505897a1f5b04336fbfc0cff65938417cae
          Files :

          • changelog.html
          • core/pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #868 [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3. Ulli Hafner : 6aa47505897a1f5b04336fbfc0cff65938417cae Files : changelog.html core/pom.xml

          Not sure were the fix went actually into, but can verify that Jenkins 1.424 has the complete fix.

          Matthias Kraft added a comment - Not sure were the fix went actually into, but can verify that Jenkins 1.424 has the complete fix.

          Code changed in jenkins
          User: Matthias Kraft
          Path:
          changelog.html
          core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly
          http://jenkins-ci.org/commit/jenkins/f5e29cbca52cdfb75a86cefe7f5dbb9f696c4160
          Log:
          [FIXED JENKINS-6439] Fixed Timeline widget's default view off by one day.

          Second part of the JENKINS-6439 fix.

          Signed-off-by: Matthias Kraft <Matthias.Kraft@softwareag.com>

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Matthias Kraft Path: changelog.html core/src/main/resources/hudson/model/BuildTimelineWidget/control.jelly http://jenkins-ci.org/commit/jenkins/f5e29cbca52cdfb75a86cefe7f5dbb9f696c4160 Log: [FIXED JENKINS-6439] Fixed Timeline widget's default view off by one day. Second part of the JENKINS-6439 fix. Signed-off-by: Matthias Kraft <Matthias.Kraft@softwareag.com>

          Code changed in jenkins
          User: Ulli Hafner
          Path:
          changelog.html
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/6aa47505897a1f5b04336fbfc0cff65938417cae
          Log:
          [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ulli Hafner Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/6aa47505897a1f5b04336fbfc0cff65938417cae Log: [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          Code changed in jenkins
          User: Ulli Hafner
          Path:
          changelog.html
          core/pom.xml
          http://jenkins-ci.org/commit/jenkins/6aa47505897a1f5b04336fbfc0cff65938417cae
          Log:
          [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ulli Hafner Path: changelog.html core/pom.xml http://jenkins-ci.org/commit/jenkins/6aa47505897a1f5b04336fbfc0cff65938417cae Log: [FIXED JENKINS-6439] Upgrade to stapler-adjunct-timeline 1.3.

          D Soa added a comment -

          This is not working in Jenkins ver. 1.537 or 1.539. Only the latest successful build is shown. No other data points on the graph. It does initially show the correct day, but the build is shown an hour later than it happened. Both the server and client are in the same timezone (CST). I'll try attaching a screenshot.

          D Soa added a comment - This is not working in Jenkins ver. 1.537 or 1.539. Only the latest successful build is shown. No other data points on the graph. It does initially show the correct day, but the build is shown an hour later than it happened. Both the server and client are in the same timezone (CST). I'll try attaching a screenshot.

          D Soa added a comment -

          On version 1.537.

          D Soa added a comment - On version 1.537.

          D Soa added a comment -

          This one shows only two data points. Still off by 1 hour.

          D Soa added a comment - This one shows only two data points. Still off by 1 hour.

          D Soa added a comment -

          I attached another screenshot from a different project. It shows 2 data points, so it isn't limited to just the latest. Still off by 1 hour.

          D Soa added a comment - I attached another screenshot from a different project. It shows 2 data points, so it isn't limited to just the latest. Still off by 1 hour.

          D Soa added a comment -

          Upgraded to 1.540. Same problem.

          D Soa added a comment - Upgraded to 1.540. Same problem.

          D Soa added a comment -

          Checked a few other projects and a pattern has emerged. All builds before 6pm CST the previous day are missing from the graph. That's midnight GMT. So only builds from the current "GMT day" are shown (and then displayed one hour later than they happened).

          D Soa added a comment - Checked a few other projects and a pattern has emerged. All builds before 6pm CST the previous day are missing from the graph. That's midnight GMT. So only builds from the current "GMT day" are shown (and then displayed one hour later than they happened).

          D Soa added a comment -

          This looks like the reason for the off by one hour problem:
          https://github.com/jenkinsci/jenkins/commit/f6ac62bfba80093b9cf3957b5055fcce2a15002a
          <j:invokeStatic var="tz" className="java.util.TimeZone" method="getDefault"/>
              var tz = ${(tz.rawOffset + tz.DSTSavings) / 3600000};
          The "fix" must have been made while we were in daylight savings time. Now that we aren't, it doesn't work.
          The timezone offset can only be calculated when given a Date as a time of reference.

          D Soa added a comment - This looks like the reason for the off by one hour problem: https://github.com/jenkinsci/jenkins/commit/f6ac62bfba80093b9cf3957b5055fcce2a15002a <j:invokeStatic var="tz" className="java.util.TimeZone" method="getDefault"/>     var tz = ${(tz.rawOffset + tz.DSTSavings) / 3600000}; The "fix" must have been made while we were in daylight savings time. Now that we aren't, it doesn't work. The timezone offset can only be calculated when given a Date as a time of reference.

          Daniel Beck added a comment -

          dsoa: This issue has been resolved and confirmed to be fixed years before you reopened it.

          Just file a new bug for the similar but clearly different issue you're seeing (if it still occurs in a recent version of Jenkins).

          Daniel Beck added a comment - dsoa : This issue has been resolved and confirmed to be fixed years before you reopened it. Just file a new bug for the similar but clearly different issue you're seeing (if it still occurs in a recent version of Jenkins).

            Unassigned Unassigned
            starfury starfury
            Votes:
            27 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated:
              Resolved: