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

[Peter Cock]

On Thu, Sep 22, 2011 at 1:24 PM, Pjotr Prins <pjotr.public14 at thebird.nl> wrote:
> Hi,
>
> On Thu, Sep 22, 2011 at 01:03:11PM +0100, Peter Cock wrote:
>> What I am trying to understand is do all those bits live in many
>> different repositories,
>
> Yes. biogems are individual efforts - we actively encourage that. You
> have to understand that the combined biogems are arguably more
> important now than the core bioruby project. Though both have their
> roles.

OK.

>> 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).
>
> git submodules are not that great. I used them for biolib. They are
> nice and not nice ;)
>
> Like I wrote, we track repositories through biogems, bio-core and
> bio-core-ext. I think you aim to check out the master repositories
> (development branch) for testing, right?  So we can write a script to
> do just that. I would prefer to track the meta-gems, as well as
> the regular biogems. Test results can be listed on biogems.info.
>
> Would it work to clone all repositories in one directory, and run
> both combined and individual tests? We can do the scripting of that.

It sounds like the buildbot software we're using for the Biopython
testing will probably not cover this use case, from their FAQ:
http://trac.buildbot.net/wiki/FAQ

"However, a project that packages several independently-developed
utilities into a single binary for users to download is more difficult,
as Buildbot does not have a means to represent the multiple
revisions from multiple repositories that must be used to make
up the single binary. For simple cases (e.g,. always building the
latest version), this can be made to work, but more complex cases
are still a work in progress."

It sounds like the best we can hope for using BuildBot is to
track a core BioRuby repository, but for the BioRuby Gems
we'd just be able to test the latest version. That would still be
better than nothing, but you wouldn't be able to easily work
out which revision of a Gem caused a problem for example.

>> > 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.
>
> Different VMs can be created. For each target one. I am primarily
> interested in a Debian VM - as that covers >80% of users in
> bioinformatics. I am not saying it replaces your installations - but
> it would certainly add to it.

OK, having a Debian VM as one of several BioRuby buildslaves
covering a range of setups makes sense.

Peter