Scott Gray wrote: > On 6/01/2010, at 10:19 AM, Adam Heath wrote: > >> Scott has said in the past that the buildbot doesn't run on every >> checkin. This means that multiple commits might be tested. Would it >> be possible to have failure messages list all of the revisions that >> are being covered, based on the last successful commit? > > This is what happens, for example take a look at the build after the one > above which covered a few commits: > http://ci.apache.org/builders/ofbiz-trunk/builds/2246
Wasn't certain, thought it might, but it's nice to have it confirmed. >> Additionally, it'd be nice if once a failure is detected, it'd either >> do an auto binary disection, to find the commit that actually failed >> in the list of covered revisions, or it could just try them all. >> >> For instance, if 891234 is good, and then 892765 fails. 892765 would >> get recorded as a state change, putting ofbiz into fail mode. It >> would then try 891562, 891840, 892496, and 892599, reporting that it >> tried these other revisions, and noticed the error first occurred at >> 892496, then ofbiz would stay in fail mode, and the buildbot would >> keep quiet until it detects that ofbiz has been fixed. > > I have no idea if buildbot is capable of this but you're more than > welcome to investigate it and request changes from infra. Standard open-source response, kinda expected it. It'd still be nice if the request was forwarded on, if it wasn't too much of a hassle. If it is, I respect that, and I'll just add it to my infinite todo list squared. > In general though I think it's usually fairly obvious what the cause of > a problem is based on a quick look at the stdio from the failed build > task. I don't think it's a huge ask for each committer on the blamelist > to take a minute or two to figure out if it's their problem or not. Computer time is free, human time is not. Computers are continually getting faster, while humans get slower. Have you had a chance to play with git bisect yet? It makes me feel squishy in my happy place.
