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

RSS feed for build status shows incorrect info for current build

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • None
    • Platform: All, OS: All

      For the currently building build the RSS feed shows something like:
      trunk #1109 (null)

      while it should show:

      trunk #1109 (IN PROGRESS)

          [JENKINS-163] RSS feed for build status shows incorrect info for current build

          RSS cannot be used to publish status of on-going builds, as once something is
          posted it cannot be changed.

          Removed ongoing builds from RSS. Will be in 1.63.

          Kohsuke Kawaguchi added a comment - RSS cannot be used to publish status of on-going builds, as once something is posted it cannot be changed. Removed ongoing builds from RSS. Will be in 1.63.

          vsizikov added a comment -

          I'm surprised. I thought that it's perfectly OK to update RSS feed.

          For example, I've seen people updating/editing their blogs and that was
          reflected in their RSS feeds.

          Actually, an ability to see via RSS what's going on in Hudson (including
          currently building builds) is very neat. And removal of the builds in process
          would confuse people a bit, since RSS will show that there are no in progress
          builds, and one would have to go to Hudson GUI to double check whether there
          were no new builds or whether some old build is stalled and running and running.

          In short, I don't know low-level technical detals of RSS, but it would be real
          good to have builds-in-progress posted in RSS feed. Extra good would be to have
          a time when the build has started, present in RSS for builds-in-progress.

          vsizikov added a comment - I'm surprised. I thought that it's perfectly OK to update RSS feed. For example, I've seen people updating/editing their blogs and that was reflected in their RSS feeds. Actually, an ability to see via RSS what's going on in Hudson (including currently building builds) is very neat. And removal of the builds in process would confuse people a bit, since RSS will show that there are no in progress builds, and one would have to go to Hudson GUI to double check whether there were no new builds or whether some old build is stalled and running and running. In short, I don't know low-level technical detals of RSS, but it would be real good to have builds-in-progress posted in RSS feed. Extra good would be to have a time when the build has started, present in RSS for builds-in-progress.

          OK, I read the ATOM spec and RSS 2.0 spec and I was wrong. They do allow the
          multiple revisions of the same news item, by combining publishing date and
          unique ID.

          Kohsuke Kawaguchi added a comment - OK, I read the ATOM spec and RSS 2.0 spec and I was wrong. They do allow the multiple revisions of the same news item, by combining publishing date and unique ID.

          Hmm. But in RSS 2.0, there's no way to update the news item without changing the
          timestamp associated with it. That means the timestamp can no longer represent
          the build timestamp, which is when the build was started.

          ATOM distinguishes the original publishing date of the news item from
          modification dates. But this change is bit tricky to handle, because now the
          model needs to treat various flavors of RSS differently.

          So I'm inclined to mark this as WONTFIX.

          Kohsuke Kawaguchi added a comment - Hmm. But in RSS 2.0, there's no way to update the news item without changing the timestamp associated with it. That means the timestamp can no longer represent the build timestamp, which is when the build was started. ATOM distinguishes the original publishing date of the news item from modification dates. But this change is bit tricky to handle, because now the model needs to treat various flavors of RSS differently. So I'm inclined to mark this as WONTFIX.

          vsizikov added a comment -

          OK, I've read RSS 2.0 specification and relevant chapters of "Developing feeds
          with RSS and Atom" book.

          > But in RSS 2.0, there's no way to update the news
          > item without changing the timestamp associated with it.

          Well, it seems that in RSS 2.0 there is no way to update the news and mark that
          the particular item is updated. The timestamp (the "pubDate") is not really a
          timestamp since it could point to any future point, ideologically it denotes a
          time when the entry should be "published".

          And, btw, why is it a problem, changing of timestamp/pubDate?

          The only way to notify reader that there were some changes in the feed (without
          full parsing of the feed by feeder and comparing the feed item by item) is to
          use lastBuidDate for "channel". While we're at it, currently Hudson does not put
          this attribute into the feed at all, and my reader says that the feed's last
          modified/updated time is N/A.

          And it seems that RSS 2.0 is such a bad format and a very loose standard, so
          that every reader have to do the whole feed parsing and uses some trickery to
          detect new changes/updates anyways. My reader (Sage) clearly compares both title
          and content for every news item. So, if Hudson would just modify titles (when
          build is done), that would work just fine for me. But see below...

          > That means the timestamp can no longer represent
          > the build timestamp, which is when the build was started.

          I probably missing something (please bear with me), but why is it a problem?

          The whole procedure to generate RSS feed could be as simple as this:

          • Get the latest N builds (currently 10?)
          • For every build:
          • Get the result.
          • If the result is null (build is not done). Get the build
            state (SCHEDULED(NOT_STARTED) or IN PROGRESS(BUILDING),
            put it in RSS title, and for the pubDate use the timestamp.
          • If the result is not null (build is done). Get the build result
            (FAILED, PASSED, etc), put it into RSS feed in the entry's title,
            as it is currently done, and put TIMESTAMP+DURATION to pubDate.
          • Put the most recent pubDate from all the N builds into lastBuildDate

          So, for every entry in the RSS feed, its "timestamp" (pubDate) is going to
          be either start date (for non-finished builds) or end date (for finished
          builds), and the "timestamp" of the entire RSS feed is going to be the most
          recent moment when some build either started or finished.

          This way we'll get the full picture about current Hudson activites via RSS feed
          (whether builds are currently building, and how many are done, and with wath
          results).

          Some more thoughts – on a model level, we could introduce something like:
          getLastStateChangeTime() that would return the time of the recent state change
          in the Build, and there could be 3 such moments: SCHEDULED - we return what is
          currently called a build's timestamp, IN_PROGRESS - when the build is actually
          started to be executing, DONE (when the build is done and results are
          available). It would be easier to use this method rather than calculate it in
          RSS creation code.

          Just in case, here's what the book says about lastBuildDate:

          lastBuildDate

          The date and time, RFC 822-style, when the feed last changed. Note the
          difference between this and channel/pubDate. lastBuildDate must be in the past.
          It is this element that feed applications should take as the "last time updated"
          value and not channel/pubDate.

          <pubDate>Sun, 12 Sep 2004 19:01:55 GMT</pubDate>

          vsizikov added a comment - OK, I've read RSS 2.0 specification and relevant chapters of "Developing feeds with RSS and Atom" book. > But in RSS 2.0, there's no way to update the news > item without changing the timestamp associated with it. Well, it seems that in RSS 2.0 there is no way to update the news and mark that the particular item is updated. The timestamp (the "pubDate") is not really a timestamp since it could point to any future point, ideologically it denotes a time when the entry should be "published". And, btw, why is it a problem, changing of timestamp/pubDate? The only way to notify reader that there were some changes in the feed (without full parsing of the feed by feeder and comparing the feed item by item) is to use lastBuidDate for "channel". While we're at it, currently Hudson does not put this attribute into the feed at all, and my reader says that the feed's last modified/updated time is N/A. And it seems that RSS 2.0 is such a bad format and a very loose standard, so that every reader have to do the whole feed parsing and uses some trickery to detect new changes/updates anyways. My reader (Sage) clearly compares both title and content for every news item. So, if Hudson would just modify titles (when build is done), that would work just fine for me. But see below... > That means the timestamp can no longer represent > the build timestamp, which is when the build was started. I probably missing something (please bear with me), but why is it a problem? The whole procedure to generate RSS feed could be as simple as this: Get the latest N builds (currently 10?) For every build: Get the result. If the result is null (build is not done). Get the build state (SCHEDULED(NOT_STARTED) or IN PROGRESS(BUILDING), put it in RSS title, and for the pubDate use the timestamp. If the result is not null (build is done). Get the build result (FAILED, PASSED, etc), put it into RSS feed in the entry's title, as it is currently done, and put TIMESTAMP+DURATION to pubDate. Put the most recent pubDate from all the N builds into lastBuildDate So, for every entry in the RSS feed, its "timestamp" (pubDate) is going to be either start date (for non-finished builds) or end date (for finished builds), and the "timestamp" of the entire RSS feed is going to be the most recent moment when some build either started or finished. This way we'll get the full picture about current Hudson activites via RSS feed (whether builds are currently building, and how many are done, and with wath results). Some more thoughts – on a model level, we could introduce something like: getLastStateChangeTime() that would return the time of the recent state change in the Build, and there could be 3 such moments: SCHEDULED - we return what is currently called a build's timestamp, IN_PROGRESS - when the build is actually started to be executing, DONE (when the build is done and results are available). It would be easier to use this method rather than calculate it in RSS creation code. Just in case, here's what the book says about lastBuildDate: lastBuildDate The date and time, RFC 822-style, when the feed last changed. Note the difference between this and channel/pubDate. lastBuildDate must be in the past. It is this element that feed applications should take as the "last time updated" value and not channel/pubDate. <pubDate>Sun, 12 Sep 2004 19:01:55 GMT</pubDate>

          vsizikov added a comment -

          One more reason to improve RSS/Atom support in Hudson:

          http://blogs.sun.com/tor/entry/netbeans_plugins_i_use_part3#comments

          People start using RSS/Atom as an interface to Hudson, to monitor it remotely,
          and the more informative (and accurate) the feeds are - the better for those tools.

          For example, in case of Netbeans build monitor, it could not only show OK/Failed
          status, but also "Build in Progress" or "Build is scheduled".

          vsizikov added a comment - One more reason to improve RSS/Atom support in Hudson: http://blogs.sun.com/tor/entry/netbeans_plugins_i_use_part3#comments People start using RSS/Atom as an interface to Hudson, to monitor it remotely, and the more informative (and accurate) the feeds are - the better for those tools. For example, in case of Netbeans build monitor, it could not only show OK/Failed status, but also "Build in Progress" or "Build is scheduled".

          > And, btw, why is it a problem, changing of timestamp/pubDate?

          Today we use the build start date as the timestamp in RSS.
          If I understand it correctly, RSS readers show this date
          alongside the entry, and so we'd like it to be the build
          timestamp (start date.)

          But when we republish the item with different status
          (like in-progress->success), then we need to update the
          timstamp, or else the reader can't tell which one is newer...
          oh ok, so I guess your suggestion is that having
          the lastBuildDate attribute in <channel> would be enough
          for readers to declare that the "success" news item is
          newer because it came in a <channel> with a newer date.

          I think your second suggestion of using timestamp+duration
          as the <pubDate> is also workable, except that the build
          timestamp is now different from the RSS feed timestamp,
          which could be confusing.

          Looking at the description of lastBuildDate you pasted,
          it now seemed like just updating this value accordingly
          should be enough for RSS readers to understand changing
          news items correctly. (I didn't look at any per-channel
          attributes, so I missed that.)

          So my current proposal is:

          with RSS 2.0:

          1. for each build, use build timestamp as the <pubDate>.
          set the latest status to the <title>, including
          the current status like PENDING/IN-PROGRESS, etc.
          Very important to keep the <guid> same.

          2. set <lastBuildDate> as the timestamp of "now".

          with ATOM:

          1. for each build, use the build timestamp as
          <issued>. set the latest status to the <title>.
          Very important to keep the <guid> same.
          <modified> is set to "now" for on-going builds,
          and set to timestamp+duration for completed builds.

          And if I understand things correctly so far, this will
          provide as much information as we can in RSS, without
          causing readers to duplicate any entries or messing up
          something.

          Kohsuke Kawaguchi added a comment - > And, btw, why is it a problem, changing of timestamp/pubDate? Today we use the build start date as the timestamp in RSS. If I understand it correctly, RSS readers show this date alongside the entry, and so we'd like it to be the build timestamp (start date.) But when we republish the item with different status (like in-progress->success), then we need to update the timstamp, or else the reader can't tell which one is newer... oh ok, so I guess your suggestion is that having the lastBuildDate attribute in <channel> would be enough for readers to declare that the "success" news item is newer because it came in a <channel> with a newer date. I think your second suggestion of using timestamp+duration as the <pubDate> is also workable, except that the build timestamp is now different from the RSS feed timestamp, which could be confusing. Looking at the description of lastBuildDate you pasted, it now seemed like just updating this value accordingly should be enough for RSS readers to understand changing news items correctly. (I didn't look at any per-channel attributes, so I missed that.) So my current proposal is: with RSS 2.0: 1. for each build, use build timestamp as the <pubDate>. set the latest status to the <title>, including the current status like PENDING/IN-PROGRESS, etc. Very important to keep the <guid> same. 2. set <lastBuildDate> as the timestamp of "now". with ATOM: 1. for each build, use the build timestamp as <issued>. set the latest status to the <title>. Very important to keep the <guid> same. <modified> is set to "now" for on-going builds, and set to timestamp+duration for completed builds. And if I understand things correctly so far, this will provide as much information as we can in RSS, without causing readers to duplicate any entries or messing up something.

          vsizikov added a comment -

          This bug is getting more and more interesting...

          > Today we use the build start date as the timestamp in RSS.
          > If I understand it correctly, RSS readers show this date
          > alongside the entry, and so we'd like it to be the build
          > timestamp (start date.)

          Yes, most RSS feeders I know present the date of entry in their GUI in one form
          ore another.

          But from users point of view, users don't care about timestamps.
          It seems that timestamp is more of internal, implementation detail to me.

          What users would like to know is when build started and finished.

          So it looks natural to present the date of the latest state change to users
          then some confusing notion of "timestamp" to users.

          For example, in current build history, some date is printed. How users
          what this date is? Why for finished build it still shows build start date?
          In what time zone is it? Should they be even aware about "timestamp" notion?

          It's just looks more natural to me as a user to see the date of the latest
          significant change in Build's life. For started builds it should be the start
          date, for finished builds it should be build's end date.

          Presenting this info in RSS feeds is also very natural. After all, RSS is used
          to deliver updates about builds to users, and for every status change, the feed
          item should provide the date of the change, not some abstract notion of
          timestamp which is of no interest to users.

          I understand that in the past timestamps were more important to identify builds,
          but now build numbers used instead, right?

          > set <lastBuildDate> as the timestamp of "now".

          Isn't this will make the feed always "has-updates" since for every download of
          the feed it would contain updated "lastBuildDate"? So it seems to me that there
          is no way to get away without recording scheduled-started-finished dates for the
          build and use them in the feeds.

          OK, I think I'll work on the code a little and experiment with some readers and
          will provide my findings and some code updates so that we'll have some more
          practical way of discussing this.

          vsizikov added a comment - This bug is getting more and more interesting... > Today we use the build start date as the timestamp in RSS. > If I understand it correctly, RSS readers show this date > alongside the entry, and so we'd like it to be the build > timestamp (start date.) Yes, most RSS feeders I know present the date of entry in their GUI in one form ore another. But from users point of view, users don't care about timestamps. It seems that timestamp is more of internal, implementation detail to me. What users would like to know is when build started and finished. So it looks natural to present the date of the latest state change to users then some confusing notion of "timestamp" to users. For example, in current build history, some date is printed. How users what this date is? Why for finished build it still shows build start date? In what time zone is it? Should they be even aware about "timestamp" notion? It's just looks more natural to me as a user to see the date of the latest significant change in Build's life. For started builds it should be the start date, for finished builds it should be build's end date. Presenting this info in RSS feeds is also very natural. After all, RSS is used to deliver updates about builds to users, and for every status change, the feed item should provide the date of the change, not some abstract notion of timestamp which is of no interest to users. I understand that in the past timestamps were more important to identify builds, but now build numbers used instead, right? > set <lastBuildDate> as the timestamp of "now". Isn't this will make the feed always "has-updates" since for every download of the feed it would contain updated "lastBuildDate"? So it seems to me that there is no way to get away without recording scheduled-started-finished dates for the build and use them in the feeds. OK, I think I'll work on the code a little and experiment with some readers and will provide my findings and some code updates so that we'll have some more practical way of discussing this.

          Alan Harder added a comment -
              • Issue 3224 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 3224 has been marked as a duplicate of this issue. ***

            vsizikov vsizikov
            vsizikov vsizikov
            Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: