Re: Running stackless-testsuite
Austin Bingham <[email protected]> Wed, 6 Aug 2014 06:54:16 +0200
| Newsgroups | gmane.comp.python.stackless |
|---|---|
| Message-ID | <CAEZidR2cW_VuOiH9jmfGjeDgxFP7fehagKVR=wu0O2AOeSaD8A@mail.gmail.com> |
--===============0512374772776524748== Content-Type: multipart/alternative; boundary=e89a8f5034dca97a5904ffeec343 --e89a8f5034dca97a5904ffeec343 Content-Type: text/plain; charset=UTF-8 Thanks for the link. Setting up a continuous integration build should not, in principle, be much of a problem. It turns out that travis doesn't directly work with bitbucket, only github, so we'll need to find an alternative. These include: 1. A different hosted CI system that supports building C programs and works with bitbucket, e.g. perhaps drone.io. This is what I'll try first. 2. Mirroring the bitbucket repo in github via hg-git and using travis. This feels clunky, but maybe it'll work better than I expect. 3. Set up a dedicated Jenkins server to do the building and testing for each commit. This isn't very difficult, but we'd need an internet-facing machine to host it. Perhaps a cheap cloud machine somewhere...I'm open to suggestions. Our hand may ultimately be forced a bit by stackless-testsuite. I'm not sure how travis, drone, etc. will work with multiple interacting repos. It may be as easy as invoking a clone and build for stackless-test in the stackless CI script. I've never tried it. I know it can work with Jenkins. In any event, that's my plan right now. Any other ideas are welcome, of course. I'll work on this as I have time. Austin On Tue, Aug 5, 2014 at 10:19 PM, Richard Tew <[email protected]> wrote: > Easy mistake to make. > > See the following link for information about the stackless-testsuite > project. It slightly predates your joining the list. > > http://www.stackless.com/pipermail/stackless/2014-July/006393.html > > Looking forward to seeing what you come up with, as it sounds like > something we've long needed. There were vague ideas that CCP might be > able to provide something similar at one point, but CCP no longer > employs any Stackless Python developers and is I assume after 13 years > of Stackless support is moving on. > > Cheers, > Richard. > > On 8/5/14, Austin Bingham <[email protected]> wrote: > > Ah, ok, I was on the completely wrong track. I had cloned > > "stackless-testsuite" from the bitbucket page and was trying to run that. > > Thanks for pointing me in the right direction. > > > > On that topic, though, what is stackless-testsuite for? It looks to be > very > > new, so is it perhaps the future home of the stackless tests? > > > > Austin > > > > > > On Mon, Aug 4, 2014 at 10:53 PM, Richard Tew <[email protected]> > > wrote: > > > >> Tests are normally run via Stackless\unittests\runAll.py > >> > >> The tests should work fine in 3.x, as we run them everytime we do a > >> release. The exception is 3.4, which requires updates to get > >> Stackless to work with it still. > >> > >> Cheers, > >> Richard. > >> > >> On 8/5/14, Austin Bingham <[email protected]> wrote: > >> > Hi all, > >> > > >> > I met Anselm and Christian at EuroPython, and I sort of hinted that > I'd > >> be > >> > happy to set up Travis (or some other similar tool) to run the > >> > stackless > >> > tests on each commit. To that end, I've built stackless from source, > >> > but > >> > I'm having mixed luck running the tests. So I've got a few questions. > >> > > >> > First, are the tests supposed to work with Python 3? The tests > >> > explicitly > >> > access the __builtin__ module, which is not AFAIK supported in Python > >> > 3. > >> It > >> > doesn't look like there's any attempt to support both version, but I > >> > thought I'd check. > >> > > >> > Second, what's the proper/expected way of running the tests? Standard > >> > unittest discovery (i.e. python -m unittest discover) seems to work > >> > fine, > >> > though nose is picking up more than it probably should (e.g. functions > >> like > >> > create_type_tests_for_module()). How should I be executing the tests? > >> > > >> > Thanks for any help on this. > >> > > >> > Austin > >> > > >> > >> _______________________________________________ > >> Stackless mailing list > >> [email protected] > >> http://www.stackless.com/mailman/listinfo/stackless > >> > > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless > --e89a8f5034dca97a5904ffeec343 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks for the link.=C2=A0<div><br></div><div>Setting up a= continuous integration build should not, in principle, be much of a proble= m. It turns out that travis doesn't directly work with bitbucket, only = github, so we'll need to find an alternative. These include:</div> <div><br></div><div>1. A different hosted CI system that supports building = C programs and works with bitbucket, e.g. perhaps <a href=3D"http://drone.i= o">drone.io</a>. This is what I'll try first.</div><div>2. Mirroring th= e bitbucket repo in github via hg-git and using travis. This feels clunky, = but maybe it'll work better than I expect.</div> <div>3. Set up a dedicated Jenkins server to do the building and testing fo= r each commit. This isn't very difficult, but we'd need an internet= -facing machine to host it. Perhaps a cheap cloud machine somewhere...I'= ;m open to suggestions.</div> <div><br></div><div>Our hand may ultimately be forced a bit by stackless-te= stsuite. I'm not sure how travis, drone, etc. will work with multiple i= nteracting repos. It may be as easy as invoking a clone and build for stack= less-test in the stackless CI script. I've never tried it. I know it ca= n work with Jenkins.</div> <div><br></div><div>In any event, that's my plan right now. Any other i= deas are welcome, of course. I'll work on this as I have time.</div><di= v><br></div><div>Austin</div></div><div class=3D"gmail_extra"><br><br><div = class=3D"gmail_quote"> On Tue, Aug 5, 2014 at 10:19 PM, Richard Tew <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]= om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Easy mistake to make.<br> <br> See the following link for information about the stackless-testsuite<br> project. =C2=A0It slightly predates your joining the list.<br> <br> <a href=3D"http://www.stackless.com/pipermail/stackless/2014-July/006393.ht= ml" target=3D"_blank">http://www.stackless.com/pipermail/stackless/2014-Jul= y/006393.html</a><br> <br> Looking forward to seeing what you come up with, as it sounds like<br> something we've long needed. =C2=A0There were vague ideas that CCP migh= t be<br> able to provide something similar at one point, but CCP no longer<br> employs any Stackless Python developers and is I assume after 13 years<br> of Stackless support is moving on.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> Cheers,<br> Richard.<br> <br> On 8/5/14, Austin Bingham <<a href=3D"mailto:[email protected]">a= [email protected]</a>> wrote:<br> > Ah, ok, I was on the completely wrong track. I had cloned<br> > "stackless-testsuite" from the bitbucket page and was trying= to run that.<br> > Thanks for pointing me in the right direction.<br> ><br> > On that topic, though, what is stackless-testsuite for? It looks to be= very<br> > new, so is it perhaps the future home of the stackless tests?<br> ><br> > Austin<br> ><br> ><br> > On Mon, Aug 4, 2014 at 10:53 PM, Richard Tew <<a href=3D"mailto:ric= [email protected]">[email protected]</a>><br> > wrote:<br> ><br> >> Tests are normally run via Stackless\unittests\runAll.py<br> >><br> >> The tests should work fine in 3.x, as we run them everytime we do = a<br> >> release. =C2=A0The exception is 3.4, which requires updates to get= <br> >> Stackless to work with it still.<br> >><br> >> Cheers,<br> >> Richard.<br> >><br> >> On 8/5/14, Austin Bingham <<a href=3D"mailto:austin.bingham@gma= il.com">[email protected]</a>> wrote:<br> >> > Hi all,<br> >> ><br> >> > I met Anselm and Christian at EuroPython, and I sort of hinte= d that I'd<br> >> be<br> >> > happy to set up Travis (or some other similar tool) to run th= e<br> >> > stackless<br> >> > tests on each commit. To that end, I've built stackless f= rom source,<br> >> > but<br> >> > I'm having mixed luck running the tests. So I've got = a few questions.<br> >> ><br> >> > First, are the tests supposed to work with Python 3? The test= s<br> >> > explicitly<br> >> > access the __builtin__ module, which is not AFAIK supported i= n Python<br> >> > 3.<br> >> It<br> >> > doesn't look like there's any attempt to support both= version, but I<br> >> > thought I'd check.<br> >> ><br> >> > Second, what's the proper/expected way of running the tes= ts? Standard<br> >> > unittest discovery (i.e. python -m unittest discover) seems t= o work<br> >> > fine,<br> >> > though nose is picking up more than it probably should (e.g. = functions<br> >> like<br> >> > create_type_tests_for_module()). How should I be executing th= e tests?<br> >> ><br> >> > Thanks for any help on this.<br> >> ><br> >> > Austin<br> >> ><br> >><br> >> _______________________________________________<br> >> Stackless mailing list<br> >> <a href=3D"mailto:[email protected]">[email protected]= </a><br> >> <a href=3D"http://www.stackless.com/mailman/listinfo/stackless" ta= rget=3D"_blank">http://www.stackless.com/mailman/listinfo/stackless</a><br> >><br> ><br> <br> _______________________________________________<br> Stackless mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"http://www.stackless.com/mailman/listinfo/stackless" target=3D"_= blank">http://www.stackless.com/mailman/listinfo/stackless</a><br> </div></div></blockquote></div><br></div> --e89a8f5034dca97a5904ffeec343-- --===============0512374772776524748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless --===============0512374772776524748==--