Opened 9 years ago

Last modified 4 years ago

#778 new defect

'latest' revision get's stuck on grid views when source step fails

Reported by: marcusl Owned by:
Priority: major Milestone: 0.9.+
Version: 0.7.12 Keywords: webstatus
Cc: rutsky.vladimir@…

Description (last modified by tardyp)

If the source step fails, and no revision is given (and thus becomes latest) these builds do not get moved of the grid, rather they are sorted as "newest" always.

The revisions should be sorted by most recent started/completed build, not just the sourcestamp's time or whatever is being used.

Change History (12)

comment:1 Changed 9 years ago by dustin

  • Milestone changed from undecided to 0.8.+

They do eventually get removed, but you're right - they're very annoying.

comment:2 Changed 9 years ago by dustin

  • Milestone changed from 0.8.+ to 0.8.1

The problem is that a build's sourcestamp changes as the build proceeds..

comment:3 Changed 9 years ago by dustin

  • Keywords web added
  • Milestone changed from 0.8.2 to 0.8.3

comment:4 Changed 8 years ago by dustin

  • Milestone changed from 0.8.3 to 0.9.+

The stamps are currently sorted by the earliest start time seen for a particular timestamp. So the 'latest' build should sort chronologically. It is annoying that it shows up, but I think it's a realistic picture of what was built, at any rate.

Let's see if we can solve this differently in the JS UI..

comment:5 Changed 8 years ago by marcusl

Preferably, they would be sorted not by timestamp, but by time of last build for said revision. Maybe that's tricky to fix?

comment:6 Changed 8 years ago by dustin

last build? Why not first build?

comment:7 Changed 8 years ago by marcusl

The last result is what I care about, and if I build an older revision again, it would phase out the "latest", or at least be just below it.

The thing is, I have a JS-style fetcher for our intranet-frontpage which gets this view and colors the projects title based on the most recent build result. Having latest at the bottom is annoying. (There are some projects that gets committed to rarely, but build each day. These sometimes fail in checkout resulting 'latest'. I can't get latest off the view until I commit a new thing.

I admit it's a narrow use case, but sorting by latest feels more natural anyway.

I should probably scratch my own itch, right? :)

comment:8 Changed 8 years ago by dustin

My thinking was that the earliest build is probably more indicative of the "natural" order of the builds; any time after that is due to builder contention, most likely. So if I have five builds of rev X at 7pm and one at 9pm, probably that change should sort earlier than a build that occurred at 7:30 - that 9pm build was probably due to a downed or slow slave or something like that.

To your particular issue - the problem is really that infrastructural issues are clouding your build status. If the checkout had succeeded but another non-code-related step failed, you'd get the same result, right?

Mozilla's done a decent job of categorizing certain kinds of failures as orange, red, or purple, but that's mostly been ad-hoc and done by patching various error-handling situations and special-casing the things that turn out the wrong color. I wonder if there's some more general way to do that?

comment:9 Changed 7 years ago by dustin

In general, grid's sourcestamp-sorting needs some work - it also confuses revisions on the default branch with revisions on the 'master' branch, for example.

comment:10 Changed 6 years ago by dustin

This will be fixed by getting rid of relative sourcestamps. The overall plan is that builds have sets of sourcestamps that are not necessarily the same as those attached to the original buildset. So, buildsets can have relative sourcestamps, but the build will replace those with absolute sourcestamps once it runs the corresponding source step. Then all status displays - not just the grid - will be able to display the revision it *actually* built, rather than "latest".

comment:11 Changed 6 years ago by rutsky

  • Cc rutsky.vladimir@… added

comment:12 Changed 4 years ago by tardyp

  • Description modified (diff)
  • Keywords webstatus added; web removed
Note: See TracTickets for help on using tickets.