> 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? Regards, Peter ___________________________________________________________ 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: http://lists.bx.psu.edu/