On Sat, Dec 3, 2011 at 8:18 AM, Joachim Durchholz <j...@durchholz.org> wrote: > That "take a test from the queue and distribute it, deal with downtimes and > failures, do some reporting"... that sounds like a wheel already invented by > Hudson/Jenkins. And if Jenkins doesn't work for Python stuff, test-on-commit > isn't exactly an uncommon demand, so something for Python should exist.
Actually, that was part of my GSoC project, to implement Jenkins (or buildbot). It didn't exactly work out too well, but the instance is still running at: http://72.14.182.119:8080/ .. aaand, actually, now that I look at it, it seems it has happily been building all this time. One of the things I wanted to do was have it automatically run the tests if something is pushed to master; this didn't work before but seems to work now. Whether something changed on the Github side, or someone else fixed something in Jenkins I don't know, but it does work well enough now. Currently, it's testing py25-27 with/without gmpy, and it could test Python 3 too as soon as we figure out how to do it with Tox (which we should do anyway). Now, the second major issue (and the reason sympy-bot exists) is testing pull requests. This is something Jenkins with Tox cannot do (currently). I did make an informal feature request for it (on IRC) and developers expressed interest in it, but obviously they have other things to do, too. I could make an actual feature request, but I don't think that would speed it up much. Now, all this work on Jenkins happened early in the summer, when sympy-bot was much less.. sophisticated than now (no webpage, less info, no python 3 support...). It seems to me that work is going in two parallel directions and this isn't good. I think we should decide which way we want to go. I'm personally still in favor of the Jenkins solution (though sympy-bot is still very nice), mostly because I don't like reinventing the wheel when a very robust solution already exists (which is what you pointed out, too). Just look at the features Aaron wants above, most of that is possible with Jenkins. Also, Ronan's work on py.test compatibility is ready, and py.test supports JUnitXML, which should give us a _lot_ of new information (eg. I believe we could graph a single test to see when it failed, not just a binary "yes/no" for the whole test suite) and interesting ways to present it. The biggest downside to Jenkins is, of course, that it cannot (for the moment) test pull requests and that's obviously very important for us - just imagine GCI without sympy-bot. :) Of course, all that about Jenkins is moot if there's no one to work on it and I'm not sure I will be able to (for the foreseeable future). Jo, if you are interested in playing around with it, I can give you admin access to the Jenkins instance (and, if needed, Ondřej can set you up with shell access on the linode server, but I think it shouldn't be needed). > > Disclaimer: I have no idea how these things work in practice, I just know > that they exist and the purpose they are serving. > > Regards, > Jo > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- Vladimir Perić -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
