Re: [galaxy-dev] Tests not being run on toolsheds?

2015-03-23 Thread Peter Cock
Hi Dave,

Can you check for stalls on the following repositories please?
They've not been tested for nearly two months:

https://toolshed.g2.bx.psu.edu/view/peterjc/clinod
Last tested 2015-01-29, Exception: Job in error state.

https://toolshed.g2.bx.psu.edu/view/peterjc/blast2go
Last tested 2015-01-29, Exception: Job in error state.

https://toolshed.g2.bx.psu.edu/view/peterjc/effectivet3
Last tested 2015-01-29, Exception: Job in error state.

https://toolshed.g2.bx.psu.edu/view/peterjc/samtools_depad
Last tested 2015-01-29, Converting local (test-data) bam to sam failed

The cause of the last failure is different (and is also failing on the Test
Tool Shed), raised separately here:

https://lists.galaxyproject.org/pipermail/galaxy-dev/2015-March/021650.html
http://dev.list.galaxyproject.org/test-base-twilltestcase-py-Converting-local-test-data-bam-to-sam-failed-tc4666509.html

--

Could you tweak the Latest revision: failing tool tests output
to include the date last tested in the table of results?

Over on the test tool shed there are plenty of recent failures
which I will email about separately - I'll report back here if I
spot any more stall entries where there tests look backlogged.

Thanks,

Peter

On Wed, Mar 18, 2015 at 1:46 PM, Dave Bouvier d...@bx.psu.edu wrote:
 Gentlemen,

 The issue with the nightly testing was due to a stalled test run blocking
 subsequent tests. I've cleared out that blockage and a manual test run
 appears to have completed successfully, as should future automated test
 runs. As always, feel free to let us know if you encounter any additional
 inexplicable behavior.

--Dave B.
___
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Tests not being run on toolsheds?

2015-03-18 Thread Dave Bouvier

Gentlemen,

The issue with the nightly testing was due to a stalled test run 
blocking subsequent tests. I've cleared out that blockage and a manual 
test run appears to have completed successfully, as should future 
automated test runs. As always, feel free to let us know if you 
encounter any additional inexplicable behavior.


   --Dave B.

On 03/18/2015 07:00 AM, Peter Cock wrote:

On Wed, Mar 18, 2015 at 10:13 AM, Peter Briggs
peter.bri...@manchester.ac.uk wrote:

Hello Peter C.

Thanks for your comments and advice Ironically after I sent that email the
tests for the next tool I looked at in the toolshed had been run in the past
couple of days.


That's good. I can also confirm that the Test Tool Shed example I
gave was tested overnight, although it looks like a novel failure:
https://testtoolshed.g2.bx.psu.edu/view/peterjc/sample_seqs


I'm interested because I've got a couple of tools that seem to work okay
when I run the tests locally, but are reported as failing on the toolshed,
and I wanted to see if I'd addressed the issue for one of them by updating
the tool dependencies.


I suggest asking on this mailing list, posting the shareable Tool Shed URL
and a copy of the error message. Hopefully it will be a simple issue
(forgetting a test file is my most common mistake), or it may be
that another tool author has seen the same error (which can happen
due to problems in Galaxy itself).


(As an aside I'd also assumed that passing tests is one of the conditions
for the tool to be marked as verified, but maybe that's not the case?)


I think there is still a human involved, but passing tests is expected
for a verified tool.


However as you say, more testing locally seems to be a good way to go -
thanks for your suggestions. I looked at planemo briefly a while ago and it
looked good. The other issue I've had with testing is actually testing tool
installation (i.e. tool_dependencies.xml) - I recall that planemo didn't
deal with that side of things, so I had to set up the environment for the
tests manually.


There is some work on tool_dependencies.xml ongoing within planemo,
John Chilton would be the person to ask (CC'd directly).


Thanks again for your advice and the links, I will investigate trying to set
up a local solution (including some CI testing!).


This is something where using planemo ought to be very useful - for
now I still do my local testing with a test Galaxy instance via:

$ ./run_tests.sh -id my_tool_id

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:
   https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
   http://galaxyproject.org/search/mailinglists/


___
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:
 https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
 http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Tests not being run on toolsheds?

2015-03-18 Thread Peter Briggs

Hello Dave

Thanks for addressing the specific issue of the tests failing to run.

Re my initial problem vis-a-vis a tool with tests that worked locally 
but failed on the toolsheds, this appears to be a result of the two 
environments using differing versions of perl. This caused the ordering 
of data in the output files to differ from the reference output in the 
tests on the toolshed.


As the tool wraps a third-party program, I've addressed this by 
explicitly specifying the version of perl that it uses (at least it 
seems to have worked for my latest version on the test toolshed - I will 
update the main toolshed next).


The repositories in question are:
https://toolshed.g2.bx.psu.edu/view/pjbriggs/pal_finder
https://testtoolshed.g2.bx.psu.edu/view/pjbriggs/pal_finder

I see a separate problem with a different tool which I'll investigate 
next and report if I can't understand the toolshed test failure.


Thanks again for your help,

Best wishes

Peter

On 18/03/15 13:46, Dave Bouvier wrote:

Gentlemen,

The issue with the nightly testing was due to a stalled test run
blocking subsequent tests. I've cleared out that blockage and a manual
test run appears to have completed successfully, as should future
automated test runs. As always, feel free to let us know if you
encounter any additional inexplicable behavior.

--Dave B.

On 03/18/2015 07:00 AM, Peter Cock wrote:

On Wed, Mar 18, 2015 at 10:13 AM, Peter Briggs
peter.bri...@manchester.ac.uk wrote:

Hello Peter C.

Thanks for your comments and advice Ironically after I sent that
email the
tests for the next tool I looked at in the toolshed had been run in
the past
couple of days.


That's good. I can also confirm that the Test Tool Shed example I
gave was tested overnight, although it looks like a novel failure:
https://testtoolshed.g2.bx.psu.edu/view/peterjc/sample_seqs


I'm interested because I've got a couple of tools that seem to work okay
when I run the tests locally, but are reported as failing on the
toolshed,
and I wanted to see if I'd addressed the issue for one of them by
updating
the tool dependencies.


I suggest asking on this mailing list, posting the shareable Tool Shed
URL
and a copy of the error message. Hopefully it will be a simple issue
(forgetting a test file is my most common mistake), or it may be
that another tool author has seen the same error (which can happen
due to problems in Galaxy itself).


(As an aside I'd also assumed that passing tests is one of the
conditions
for the tool to be marked as verified, but maybe that's not the case?)


I think there is still a human involved, but passing tests is expected
for a verified tool.


However as you say, more testing locally seems to be a good way to go -
thanks for your suggestions. I looked at planemo briefly a while ago
and it
looked good. The other issue I've had with testing is actually
testing tool
installation (i.e. tool_dependencies.xml) - I recall that planemo didn't
deal with that side of things, so I had to set up the environment for
the
tests manually.


There is some work on tool_dependencies.xml ongoing within planemo,
John Chilton would be the person to ask (CC'd directly).


Thanks again for your advice and the links, I will investigate trying
to set
up a local solution (including some CI testing!).


This is something where using planemo ought to be very useful - for
now I still do my local testing with a test Galaxy instance via:

$ ./run_tests.sh -id my_tool_id

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:
   https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
   http://galaxyproject.org/search/mailinglists/



--
Peter Briggs peter.bri...@manchester.ac.uk
Bioinformatics Core Facility University of Manchester
B.1083 Michael Smith Bldg Tel: (0161) 2751482
___
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:
 https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
 http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Tests not being run on toolsheds?

2015-03-18 Thread Peter Briggs
Thanks Peter. I've reported the details of the specific tool that I was 
having problems with in my message to Dave B.


planemo already looks really good, if it could handle the tool 
dependencies as well then that would be the icing on the cake.


Thanks for your help, best wishes

Peter

On 18/03/15 11:00, Peter Cock wrote:

On Wed, Mar 18, 2015 at 10:13 AM, Peter Briggs
peter.bri...@manchester.ac.uk wrote:

Hello Peter C.

Thanks for your comments and advice Ironically after I sent that email the
tests for the next tool I looked at in the toolshed had been run in the past
couple of days.


That's good. I can also confirm that the Test Tool Shed example I
gave was tested overnight, although it looks like a novel failure:
https://testtoolshed.g2.bx.psu.edu/view/peterjc/sample_seqs


I'm interested because I've got a couple of tools that seem to work okay
when I run the tests locally, but are reported as failing on the toolshed,
and I wanted to see if I'd addressed the issue for one of them by updating
the tool dependencies.


I suggest asking on this mailing list, posting the shareable Tool Shed URL
and a copy of the error message. Hopefully it will be a simple issue
(forgetting a test file is my most common mistake), or it may be
that another tool author has seen the same error (which can happen
due to problems in Galaxy itself).


(As an aside I'd also assumed that passing tests is one of the conditions
for the tool to be marked as verified, but maybe that's not the case?)


I think there is still a human involved, but passing tests is expected
for a verified tool.


However as you say, more testing locally seems to be a good way to go -
thanks for your suggestions. I looked at planemo briefly a while ago and it
looked good. The other issue I've had with testing is actually testing tool
installation (i.e. tool_dependencies.xml) - I recall that planemo didn't
deal with that side of things, so I had to set up the environment for the
tests manually.


There is some work on tool_dependencies.xml ongoing within planemo,
John Chilton would be the person to ask (CC'd directly).


Thanks again for your advice and the links, I will investigate trying to set
up a local solution (including some CI testing!).


This is something where using planemo ought to be very useful - for
now I still do my local testing with a test Galaxy instance via:

$ ./run_tests.sh -id my_tool_id

Peter



--
Peter Briggs peter.bri...@manchester.ac.uk
Bioinformatics Core Facility University of Manchester
B.1083 Michael Smith Bldg Tel: (0161) 2751482
___
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:
 https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
 http://galaxyproject.org/search/mailinglists/