[users at bb.net] 0.9.3, mostly finished, and another question.
ngilmore at grammatech.com
Wed Feb 1 16:28:03 UTC 2017
Thanks for the advice.
I see that the key is to go through master.data more than trying to go
through the object instances and their parents/sibling/children.
On 2/1/2017 10:22 AM, Pierre Tardy wrote:
> Hi Neil,
> My goto code for examples on how to get stuff from the data API is here:
> I would suggest you to copy some part of this code
> something like this should work:
> buildsteps = yield defer.gatherResults(
> [master.data.get(("builds", build['buildid'], 'steps'))
> for build in builds])
> for s in buildsteps:
> if step['name'] in interresting_step_names:
> s['logs'] = yield master.data.get(("steps", s['stepid'],
> for l in s['logs']:
> first_100_lines = yield master.data.get(("logs",
> l['logid'], 'contents', resultSpec=resultspec.ResultSpec(offset=0,
> Le mer. 1 févr. 2017 à 17:08, Neil Gilmore <ngilmore at grammatech.com
> <mailto:ngilmore at grammatech.com>> a écrit :
> Hi everyone.
> Thanks to everyone on this list, and Pierre's patches in
> particular, we
> now have our masters running 0.9.3, with a couple, um,
> enhancements. In
> particular, we're using Pierre's patches to enable reconfiguration in
> the schedulers. My users thank you.
> We did see a few oddities upon restarting the masters, though. Quite a
> few of our builders reported 2 builds running for a builder at the
> time. And one builder even had an intervening build between the
> two that
> were building.
> And now the question.
> Back last fall, I inquired as to why our custom build step was failing
> to produce a correct log (I haven't had a chance to follow up on this
> particular item since then). Here's code:
> class MyCustomStep(ShellCommand):
> name = "errorlog"
> haltOnFailure = 1
> description = ["checking for errors"]
> descriptionDone = ["done checking for errors"]
> OFFprogressMetrics = ('output',)
> # things to track: number of files compiled, number of
> # traversed (assuming 'make' is being used)
> def createSummary(self, cmd):
> Pierre's response that synchronous logs don't really work any more is
> fine, and he offered this instead:
> first_100_lines = yield self.master.data.get(("logs", log['logid'],
> "contents"), resultSpec=resultspec.ResultSpec(offset=0, limit=100))
> Unfortunately, I haven't been too successful at getting a log id from
> inside of createSummary(). Is there any easy way to do that? (if
> knows off the top of their head, it'll save me some work).
> My current fix was to change master.cfg have our mail stuff use stdio
> instead of stdio_head, and have the mail code to cut down the log
> to 64K
> there. This didn't quite have the intended effect.
> I'd sort of thought that only the logs for the failed steps would be
> included. I was wrong. Any log in the build named stdio for any step
> would be included. On the bright side, they're all cut down to 64K or
> less. On the less-than-bright side, sometimes we get many logs
> (to the point where some emails were getting caught by an email list
> waiting for moderator approval, as they got too large for the
> lists' limit).
> So it looks like I'm back to spelunking the code to find a log id. My
> other option (which is really a hack) is to know that stdio_head
> is only
> generated in steps named errorlog, and only process those.
> Neil Gilmore
> grammatech.com <http://grammatech.com>
> users mailing list
> users at buildbot.net <mailto:users at buildbot.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users