pyd - continuous integration
So pyd is at the point where it really needs some sort of test suite runner. It's kind of complicated since I need to test against * multiple versions of dmd/ldc/gdc * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) * redhat, ubuntu, osx, windows, etc Does anyone have any suggestions on how or where to set this up? I had a peek at atlassian bamboo, but it looks like it only plays with ec2, which I don't know anything about.
Re: pyd - continuous integration
On Monday, 9 June 2014 at 22:37:20 UTC, Ellery Newcomer wrote: So pyd is at the point where it really needs some sort of test suite runner. * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) Well done! -If you want a suggestion I think you should starting support for: +2.6! Matheus.
Re: pyd - continuous integration
On Monday, 9 June 2014 at 22:37:20 UTC, Ellery Newcomer wrote: So pyd is at the point where it really needs some sort of test suite runner. It's kind of complicated since I need to test against * multiple versions of dmd/ldc/gdc * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) * redhat, ubuntu, osx, windows, etc Does anyone have any suggestions on how or where to set this up? I had a peek at atlassian bamboo, but it looks like it only plays with ec2, which I don't know anything about. Bamboo can be hosted locally on your own machines without having to deal with EC2 in any way. It's just that if you want remote test runners (as well as not being free unless you can get an open source license from Atlassian), EC2 is one of the available options to run instances on. I actually use Bamboo with a plugin I made (https://shardsoft.com/stash/projects/SHARD/repos/dubplug/browse) for my own stuff, but this plugin is far from being complete and doesn't really handle dependencies at all (as well as currently relying on the text format of test output with 'tested' not changing...). I have my instance running on my server, with the web interface at https://shardsoft.com/bamboo/browse/SHARD-SHTOOLS. A very popular choice for D users is TravisCI, which I believe is free for open source and by default handles multiple platforms, something which Bamboo does not easily do in the $10 version.
Re: pyd - continuous integration
On Mon, 2014-06-09 at 22:37 +, Ellery Newcomer via Digitalmars-d wrote: > So pyd is at the point where it really needs some sort of test > suite runner. It's kind of complicated since I need to test > against > > * multiple versions of dmd/ldc/gdc > * multiple versions of python (2.4 - 3.4, but I'm thinking of > dropping 2.4 and 2.5 this year) Unless there is an extant user base for 2.4 and 2.5, I would drop them with immediate effect, which would allow to upgrade to a reasonable Python code quality. There are very few people still stuck with 2.5 even fewer with 2.4 and increasingly 2.6 is going away (but not totally thanks to Red Hat :-( I suggest ignoring 3.0, 3.1 and 3.2, and supporting only 3.3 and later. This gives a much greater chance of having a single Python codebase executable with either 2.7 or 3.3/3.4. So if you can drop 2.6 as well, things get almost livable with. Personally I only use 3.4, but there are those who will not upgrade and insist on using 2.7. > * redhat, ubuntu, osx, windows, etc Fedora and Debian. > Does anyone have any suggestions on how or where to set this up? > I had a peek at atlassian bamboo, but it looks like it only plays > with ec2, which I don't know anything about. There is TeamCity, I am involved in a couple of projects using that. Works well and (unsurprisingly) had excellent support in IntelliJ IDEA and PyCharm. Bamboo can be a bit of a pain, but once set up work well. I am using the Codehaus instance because some of the project I work on are Codehaus projects. You could run Jenkins somewhere. I guess the issue is being able to set up 9 or 10 virtual machines for all the variants needed. Perhaps a good solution would be to run Buildbot, have the server local to you and ask for volunteers to offer slaves. This used to work very well for me for a now dead project. It also used to work excellently for the SCons project, but since the exit of the two main developers, there has been a bit of hiatus. This is being fixed now, and a good Buildbot set up being put in place. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: pyd - continuous integration
On 10/06/14 00:37, Ellery Newcomer wrote: So pyd is at the point where it really needs some sort of test suite runner. It's kind of complicated since I need to test against * multiple versions of dmd/ldc/gdc * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) * redhat, ubuntu, osx, windows, etc Does anyone have any suggestions on how or where to set this up? I had a peek at atlassian bamboo, but it looks like it only plays with ec2, which I don't know anything about. Travis CI supports multi-platform, currently Linux (Ubuntu) and OS X. There's also a similar service which uses Windows. -- /Jacob Carlborg
Re: pyd - continuous integration
On 6/10/14, 1:31 AM, Russel Winder via Digitalmars-d wrote: On Mon, 2014-06-09 at 22:37 +, Ellery Newcomer via Digitalmars-d wrote: So pyd is at the point where it really needs some sort of test suite runner. It's kind of complicated since I need to test against * multiple versions of dmd/ldc/gdc * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) Unless there is an extant user base for 2.4 and 2.5, I would drop them with immediate effect, which would allow to upgrade to a reasonable Python code quality. There are very few people still stuck with 2.5 even fewer with 2.4 and increasingly 2.6 is going away (but not totally thanks to Red Hat :-( I suggest ignoring 3.0, 3.1 and 3.2, and supporting only 3.3 and later. This gives a much greater chance of having a single Python codebase executable with either 2.7 or 3.3/3.4. So if you can drop 2.6 as well, things get almost livable with. Personally I only use 3.4, but there are those who will not upgrade and insist on using 2.7. * redhat, ubuntu, osx, windows, etc Fedora and Debian. Does anyone have any suggestions on how or where to set this up? I had a peek at atlassian bamboo, but it looks like it only plays with ec2, which I don't know anything about. There is TeamCity, I am involved in a couple of projects using that. Works well and (unsurprisingly) had excellent support in IntelliJ IDEA and PyCharm. Bamboo can be a bit of a pain, but once set up work well. I am using the Codehaus instance because some of the project I work on are Codehaus projects. You could run Jenkins somewhere. I guess the issue is being able to set up 9 or 10 virtual machines for all the variants needed. Perhaps a good solution would be to run Buildbot, have the server local to you and ask for volunteers to offer slaves. This used to work very well for me for a now dead project. It also used to work excellently for the SCons project, but since the exit of the two main developers, there has been a bit of hiatus. This is being fixed now, and a good Buildbot set up being put in place. In regards to setting up virtual machines the folks at my work use Vagrant. I don't have experience with this but I thought I'd mention it in case it helps.
Re: pyd - continuous integration
If you can spare the time / HW resources, I'd probably go with Vagrant and Buildbot, but then again I would since I'm familiar with both. Atila On Tuesday, 10 June 2014 at 14:34:13 UTC, David Gileadi wrote: On 6/10/14, 1:31 AM, Russel Winder via Digitalmars-d wrote: On Mon, 2014-06-09 at 22:37 +, Ellery Newcomer via Digitalmars-d wrote: So pyd is at the point where it really needs some sort of test suite runner. It's kind of complicated since I need to test against * multiple versions of dmd/ldc/gdc * multiple versions of python (2.4 - 3.4, but I'm thinking of dropping 2.4 and 2.5 this year) Unless there is an extant user base for 2.4 and 2.5, I would drop them with immediate effect, which would allow to upgrade to a reasonable Python code quality. There are very few people still stuck with 2.5 even fewer with 2.4 and increasingly 2.6 is going away (but not totally thanks to Red Hat :-( I suggest ignoring 3.0, 3.1 and 3.2, and supporting only 3.3 and later. This gives a much greater chance of having a single Python codebase executable with either 2.7 or 3.3/3.4. So if you can drop 2.6 as well, things get almost livable with. Personally I only use 3.4, but there are those who will not upgrade and insist on using 2.7. * redhat, ubuntu, osx, windows, etc Fedora and Debian. Does anyone have any suggestions on how or where to set this up? I had a peek at atlassian bamboo, but it looks like it only plays with ec2, which I don't know anything about. There is TeamCity, I am involved in a couple of projects using that. Works well and (unsurprisingly) had excellent support in IntelliJ IDEA and PyCharm. Bamboo can be a bit of a pain, but once set up work well. I am using the Codehaus instance because some of the project I work on are Codehaus projects. You could run Jenkins somewhere. I guess the issue is being able to set up 9 or 10 virtual machines for all the variants needed. Perhaps a good solution would be to run Buildbot, have the server local to you and ask for volunteers to offer slaves. This used to work very well for me for a now dead project. It also used to work excellently for the SCons project, but since the exit of the two main developers, there has been a bit of hiatus. This is being fixed now, and a good Buildbot set up being put in place. In regards to setting up virtual machines the folks at my work use Vagrant. I don't have experience with this but I thought I'd mention it in case it helps.
Re: pyd - continuous integration
On Tuesday, 10 June 2014 at 14:39:25 UTC, Atila Neves wrote: If you can spare the time / HW resources, I'd probably go with Vagrant and Buildbot, but then again I would since I'm familiar with both. Atila I stumbled on vagrant a few months ago but haven't had a chance to play with it yet. I take it you need a pretty beefy box to use it? Another thing I was envisioning is a web page that shows test results for each combination so that it is easy for a casual user to determine pyd's status. Does buildbot have this sort of thing?
Re: pyd - continuous integration
On 10/06/14 23:32, Ellery Newcomer wrote: Another thing I was envisioning is a web page that shows test results for each combination so that it is easy for a casual user to determine pyd's status. Does buildbot have this sort of thing? Travis CI does have that. But it currently doesn't support Windows. -- /Jacob Carlborg
