[users at bb.net] 0.9.3, mostly finished, and another question.
ngilmore at grammatech.com
Wed Feb 1 16:08:52 UTC 2017
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 same
time. And one builder even had an intervening build between the two that
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:
name = "errorlog"
haltOnFailure = 1
description = ["checking for errors"]
descriptionDone = ["done checking for errors"]
OFFprogressMetrics = ('output',)
# things to track: number of files compiled, number of directories
# 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 anyone
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 attached
(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.
More information about the users