Hi MPL devs,
I think I've fixed a long-standing issue we've had with the buildbot
where sometimes a false alarm was issued when two tests stepped on each
others' toes. Specifically, I've fixed up the MPL buildbot environment
on the virtual machine that runs both the Python 2.4 and 2.5 tests so
that these tests are run from different MPLCONFIGDIRs.
Andrew et al,
Please see my comment in the above bug ticket. I'm curious about three things:
1) Would the solution I suggested in that comment also have worked? If so, would it be more robust against future changes in the buildbot, or the creation of new buildbots? Or was I misunderstanding where the buildbot code comes from, and how it works?
Your comment on the tracker was:
Having two buildbot processes
accessing, and potentially writing to, the same cache file(s) partly
defeats the purpose of the buildbot: testing independent builds
independently, on a variety of systems.
The fact that we have two simultaneous build/test cycles happening on
one test system is simply a result of the way I configured the
buildbot. (I’m running a Python 2.4 and Python 2.5 interpreter
simultaneously on the same machine.) I wouldn’t call it a failure of
the buildbot software at all.
The solution you proposed in the comment was close to what I
implemented. The difference is I didn’t use tempfile.mkdtemp but just
fixed the value per buildbot slave.
2) Can the bug be closed now?
Yes, I closed it.
So, from now on, all emails from the buildbot should be taken seriously.
3) What about the failure that occurred after your 8609 commit?
If you look at the log, that was because there was trouble downloading
pygments. (I should disable networking on the build slaves, but
haven’t…) The next build didn’t have that issue.
It looks like the scons build is not being run, but it's last failure (in November) is still triggering the email. Correct?
No, the buildbot is currently configured only to send a single email on
the transition from OK → failure for a given slave. So there was
one email sent about this, but shouldn’t be any more.
So, again, we can take all emails from the buildbot seriously.
···
https://sourceforge.net/tracker/?func=detail&aid=2856125&group_id=80706&atid=560720