Summary: | Failed Assertion in iteration.openSourceRevision at build.webkit.org/dashboard | ||
---|---|---|---|
Product: | WebKit | Reporter: | Matthew Hanson <matthew_hanson> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | ap, dbates, dfarler, timothy, webkit-bug-importer |
Priority: | P3 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://build.webkit.org/dashboard/ |
Description
Matthew Hanson
2014-01-23 10:46:13 PST
This might be when looking at a revision that hasn't finished svn step yet, so there is no revision known. Matt, is this something you intend to tackle soon? If not, I'd like to look into this. Alexey, I think that you are right. I'm going to be working on the periodically dashboard today and tomorrow, so I'll go ahead and tackle this one. This is in fact what is happening. We can functionally eliminate this from happening if we parse the revision number out of the object indexed by the "currentStep" key when the current step is named "svn". This fix would leave susceptible to assertion failure during the configure_build step, but the configure_build step typically completes in << 1 second. We can handle this at the moment by adding logic to circumvent the assertion when the state is equal to configure_build. This type of fix will be brittle in that the check will need to be updated every time that a new step is added ahead of svn. Ideally we would extend the buildbot API so that we could query an endpoint to determine the order of a step relative to another, per machine. (In reply to comment #4) > This is in fact what is happening. We can functionally eliminate this from happening if we parse the revision number out of the object indexed by the "currentStep" key when the current step is named "svn". Is this asserting when trying to show checkout information? If this property means what I think it means, asserting console.assert(iteration.openSourceRevision) doesn't match up with how buildbot populates got_revision. It's valid for got_revision to be undefined until a checkout occurs (and might still be undefined if the server goes down :)). Similarly, "revision" really ought to be named "requestedRevision" because it's also perfectly fine for this to be undefined (e.g. None -> checkout HEAD). > > This fix would leave susceptible to assertion failure during the configure_build step, but the configure_build step typically completes in << 1 second. We can handle this at the moment by adding logic to circumvent the assertion when the state is equal to configure_build. > > This type of fix will be brittle in that the check will need to be updated every time that a new step is added ahead of svn. Ideally we would extend the buildbot API so that we could query an endpoint to determine the order of a step relative to another, per machine. Build steps should appear ordered in the JSON, although that doesn't matter much - you can just filter the svn step -> isFinished if got_revision is unknown and display something like "Checkout out ...". Also, there may be no revision for "clean build" iterations, which only clean the build, and don't check out or build anything. *** This bug has been marked as a duplicate of bug 153262 *** |