Closed Bug 413727 Opened 16 years ago Closed 14 years ago

TinderboxPushlog should be able to show progress (e.g. partial logs)

Categories

(Release Engineering :: General, enhancement, P5)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ted, Assigned: joduinn)

Details

(Whiteboard: [automation][reporting][tinderbox][triagefollowup])

bhearsum tells me that he's working on getting a public mirror of the try server buildbot waterfall, so I think we should get one of those for the unit test boxes eventually.  Once we get that, we should make the buildbots show their actual progress on the waterfall display.  It's pretty easy:
http://buildbot.net/repos/release/docs/buildbot.html#Adding-LogObservers
http://mavra.perilith.com/~luser/utils.txt (see RegressionSearchOutputParser).
Severity: normal → enhancement
Mass move of Core:Testing bugs to mozilla.org:ReleaseEngineering. Filter on RelEngMassMove to ignore.
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Version: Trunk → other
Component: Release Engineering → Release Engineering: Future
we are running the unit test suites concurrently and as a result there is some information given sooner.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
That doesn't really address the request.  M and E still take 30-40 minutes each.

What would address it is being able to click a grey M or E on http://tests.themasta.com/tinderboxpushlog/ and see a partial log and whether there have been any failures so far.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Hi Jesse, we won't be able to do this with the current buildbot -> tinderbox setup that we have.

As we were talking in our bug triage this would not be something that we will be able to fix with tinderbox (it was not designed for it) specially if we are planning to move away from it at some point.

At some point we would want to have this not only for unit test but for the logs of everything.

If there is another bug tracking this let's close this one and if there isn't we can make the summary more specific to keep track that this should be a feature of the post-tinderbox reporting tool.

Makes sense?
Yes, makes sense.
Summary: unit test boxes should show progress on waterfall → TinderboxPushlog should be able to show progress (e.g. partial logs)
As filed, this bug was to display this information on the buildbot waterfall, under the assumption that we would be making a cached copy of that available somewhere. Since we're clearly not going to do that, it makes sense to morph this to something that could be implemented with the buildbot database.
Seems like the obvious thing to do here would be to expose the underlying buildbot data in JSON form so that tbpl could read it.

My memory is that tinderbox has a JSON data feed, but that mstange found it insufficient for tbpl, so he's actually parsing the tinderbox HTML output instead.

It would be great if the data we get from the buildbot database to fix this were in a format sufficient to *replace* tbpl's current tinderbox data source, so that tbpl could stop depending on tinderbox.

But mstange probably knows more here.
(In reply to comment #7)
> It would be great if the data we get from the buildbot database to fix this
> were in a format sufficient to *replace* tbpl's current tinderbox data source,
> so that tbpl could stop depending on tinderbox.
> 

I *think* this is the plan. It's a bit of a ways off still, though. We've got Buildbot throwing status information into a database in our staging setup - but no production data yet. Once we do have that, however, it won't be hard to expose it for tbpl and others to consume.
(In reply to comment #7)
> My memory is that tinderbox has a JSON data feed, but that mstange found it
> insufficient for tbpl, so he's actually parsing the tinderbox HTML output
> instead.

Not anymore. At the beginning I was using it because I hadn't known about the JSON, but after about two weeks I switched to the JSON data feed.

(In reply to comment #8)
> I *think* this is the plan.

I thought so too. :)
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P5
Whiteboard: [automation][reporting]
Assignee: nobody → joduinn
Whiteboard: [automation][reporting] → [automation][reporting][tinderbox][triagefollowup]
Lots have changed since this bug was originally filed in January 2008.

bug#530318 posts logs to ftp.m.o, in the same directory as the build. Each logfile is uploaded at the end of its step in build/test process, so linux-opt log uploaded when linux-opt build is uploaded, win32-mochitest1 log uploaded when win32-mochitest1 completed, etc. Uploading individual logs per step like this is part-way solution here, and doable compared to having streaming live line-by-line logs updating to multiple clients.

Separate topic raised here, is about TBPL access buildbot data directly (either through scheduler db or through json feed), and no longer needing to scrap tinderbox waterfall html. This was done in bug#585682.

Please reopen if I missed anything.
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → FIXED
Not fixed.

This is about showing the logs of builds as they progress (which buildbot can do), which can help to see if bustage is fixed well before the build completes.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I discussed this with joduinn; it sounds like this would cause significant load on the buildbot masters, and it's probably not worthwhile spending resources on relative to just getting faster builds, tests, etc., which solves essentially the same problem.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → WONTFIX
John, mind clarifying on comment 11?

I can't find logs per step mentioned in bug 530318. I didn't dive deeply into the ftp archives, but, say, http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-debug/1287698694/ doesn't look like it's having logs per step, either.

(FTR, I don't see a reason why the master had to be in charge here.)
Not step in the buildbot sense, instead in the whole dependent tree of jobs that come from a push.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.