[BioRuby] Nightly build testing, was: Broken link on wiki installation page

[Fields, Christopher J]

On Sep 22, 2011, at 7:03 AM, Peter Cock wrote:

> On Thu, Sep 22, 2011 at 6:21 AM, Pjotr Prins <pjotr.public14 at thebird.nl> wrote:
>> Hi Peter,
>> 
>> It is for reason of limited installs we have meta-packages.
>> Meta-packages provide a sense of stability, and is what most users
>> will install.
>> 
>> I suggest testing for:
>> 
>>  - bio
>>  - bio-core, which contains core pure ruby biogems
>>  - bio-core-ext, which contains non-pure ruby biogems
>>    (extensions)
>> 
>> anything worth testing will be in there. We can help create the test
>> scripts for those packages.
> 
> What I am trying to understand is do all those bits live in many
> different repositories, or is there one super repository? And if
> there isn't a single repository, can we create a meta-repository
> (e.g. using git submodules).

This is the plan for bioperl; namely tying together working code from various soon-to-be-split repos. One could then checkout the parent repo and the specific versions of the submodules, with the end game of tagging releases of the parent to specific commits/tags/branches of working submodules.  

Of course I haven't tested this extensively (just started looking into it recently), not even sure tagging of the parent is possible, though if it isn't it certainly diminishes any utility of 'git submodule'.  And I'm not sure how maintainable that will be in the long run.

>> Also, it looks like the testing environment should be hosted in a
>> ready made VM image. I can create a CloudBioLinux flavour for that.
>> Once we know what to install. I will also want tests for biolib_hpc,
>> when that gets production ready (btw). It is a long standing wish on
>> my end to get this sorted.
> 
> Perhaps I have misunderstood you, but if all the build slaves
> run the tests via the same VM image, there is no diversity.
> For Biopython we deliberately want inhomogeneous setups
> for our buildslaves to try and cover the variety of potential
> setups our end users will have.
> 
> Peter

The way this is handled via perl is to either use smoke testing during the build (as Peter alluded to earlier) or to run tests during CPAN installation.  Either one requires a little more overhead, but in re: to the latter we do get a nice spread of OS and perl versions to test against:

  http://matrix.cpantesters.org/?dist=BioPerl+1.6.901

(obviously from that link we need windows devs to help out, they seem to be scarce these days :)

We don't have smoke set up for bioperl yet (this would allow testing the repo on a more regular basis instead of per-release), though installation of Smolder on testing.open-bio.org was mentioned at one point but fell through the cracks.

chris