> On Mar 17, 2013, at 2:25 PM, Björn Grüning wrote:
>> Maybe its possible to run a few selected toolshed tools in an automatic
>> test suite before each release or after such large changes. We have
>> really complex tools in the toolshed that uses mainly all features
>> available.
>> Have a nice weekend!
>> Bjoern

On Sun, Mar 17, 2013 at 10:35 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
> A new next-stable branch on Galaxy central is currently scheduled for
> tomorrow ...
> This branch includes a new tool shed test framework component that will
> discover all tool shed repositories  that contain tools.  ..., the test
> framework will install the repository into a Galaxy instance and run the
> functional test defined for each tool. ...

These Tool Shed developments are definitely going to be a big
step forward for automated testing - but that doesn't address
the problem at hand: The <parallelism> code using the
TaskedJobWrapper would only get tested if this is enabled
in the Galaxy system being tested. Inevitably as more features
are added to Galaxy itself, included more complicated job
runners for different computer/grid back ends, covering them
all will require a suite of Galaxy test servers. That's hard.

I can see why the <parallelism> code isn't enabled by default
on the main public Galaxy - the job splitting and merging adds
additional IO and compute load, so does not make sense on
a large and heavily used cluster (overall it will only slow jobs
down). I suspect it is more suited to local institute clusters
which are not typically under full load - where it helps by
making each individual job complete more quickly.

Perhaps there is a case for one of the Galaxy core team's
development instances to run with  <parallelism> enabled?



Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:


Reply via email to