Le samedi 03 décembre 2011 à 11:39 +0100, Vladimir Perić a écrit : > 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
I played with Jenkins settings several weeks ago and set it up to poll GitHub every five minutes, so that it tests master every time something is pushed. It's been working fine, except that Jenkins hung up trying to clone the repository a few times and I had to abort the run manually. > 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). We should also test with pypy (and here Jenkins is useful, since testing under pypy is so slow that it's probably not a good idea to do it in sympy-bot). > > 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). I can try setting up py3 and pypy (which does require shell access, I think), and maybe py.test. -- 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.
