-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Platform: All, OS: All
-
Powered by SuggestiMate
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
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.
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.
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>
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.
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.
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.