Hi Peter,

On Jan 29, 2014, at 12:55 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

Hi all,

Are both the main and test Tool Sheds currently meant to be running nightly tests again?

Yes

I've not really got back into Galaxy tool testing since Christmas. Most of my tools' test results look sensible, but there seem to be some issues still, e.g.

http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler Not tested since 2014-01-04

I've reset the do_not_test column on the record above ( it was set to not allow testing ), so it should now be tested.

http://toolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr 2014-01-29 missing blast_datatypes dependency (why?) 2014-01-28 showing failed tests for sambamba_filter (wrong tool)

I'll have to take a look at the above issue. I'm completely swamped though, so it will be a while.

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/

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

On Thu, Jan 30, 2014 at 4:32 PM, Greg Von Kuster greg@bx.psu.edu wrote:

Hi Peter,

On Jan 29, 2014, at 1:18 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Hi Peter,

...

http://toolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr 2014-01-29 missing blast_datatypes dependency (why?) 2014-01-28 showing failed tests for sambamba_filter (wrong tool)

I'll have to take a look at the above issue. I'm completely swamped though, so it will be a while.

I believe I have the above issue resolved in 12331:fd4936ae8219 ( at least I took a step in the right direction ). We'll have to wait for tonight's test run to make sure everything is handled correctly.

Thanks for letting me know about this.

Greg Von Kuster

Fingers crossed :)

Thanks,

Peter

Hi Peter,

I've created the following Trello card for this. I know what the problems are, but I won't have time to get fixes for them for a while. Please continue to reposrt issues you discover and I'll make sure to get fixes as soon as I get time.

https://trello.com/c/M1rwVWhI/143-nightly-test-runs-1

Thanks

Greg Von Kuster

On Feb 3, 2014, at 7:01 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Thu, Jan 30, 2014 at 4:32 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

On Jan 29, 2014, at 1:18 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Peter wrote:

...

http://toolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr 2014-01-29 missing blast_datatypes dependency (why?) 2014-01-28 showing failed tests for sambamba_filter (wrong tool)

I'll have to take a look at the above issue. I'm completely swamped though, so it will be a while.

I believe I have the above issue resolved in 12331:fd4936ae8219 ( at least I took a step in the right direction ). We'll have to wait for tonight's test run to make sure everything is handled correctly.

Hi again Greg,

That one is still weird - was that fix deployed to the main toolshed?

http://toolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr

Moreover there is a similar problem with the matching repository on the Test Tool Shed,

http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr 2014-01-04 showing failed tests for proteomics_search_tandem_1 2013-12-20 showing failed tests for proteomics_search_tandem_1 2013-12-18 tests for blastxml_to_top_descr passed 2013-12-17 tests for blastxml_to_top_descr passed

--

Returning to the MIRA4 problem, I got a meaningful test failure which I fixed (I hadn't set an environment variable in the install script), but I now get only partial test output:

http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler Not datestamped (a glitch if there is only one test entry?):

Automated tool test results Automated test environment Time tested: 2014-02-03 16:25:08 System: Architecture: Python version: Galaxy revision: Galaxy database version: Tool shed revision: 12332:d9f6f3f24671 Tool shed database version: 22 Tool shed mercurial version: 2.2.3 Tools missing tests or test data Tool id: mira_4_0_mapping Tool version: 0.0.2 Tool guid: testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_mapping/0.0.2 Missing components: Functional test definitions missing for mira_4_0_mapping. Tool id: mira_4_0_de_novo Tool version: 0.0.2 Tool guid: testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_de_novo/0.0.2 Missing components: Functional test definitions missing for mira_4_0_de_novo.

That's all fine, but where are the test results for mira_bait which I would expect to pass?

Thanks,

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/

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

Hi Peter,

The following issue was corrected in change set https://bitbucket.org/galaxy/galaxy-central/commits/e3a4d4d813fdb8a34cfd6d59...

On Jan 29, 2014, at 12:55 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

http://toolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr 2014-01-29 missing blast_datatypes dependency (why?) 2014-01-28 showing failed tests for sambamba_filter (wrong tool)

I'll be taking a look at the remaining issues on the following Trello card next.

https://trello.com/c/M1rwVWhI/143-nightly-test-runs-1

Greg Von Kuster

On Sat, Feb 15, 2014 at 12:25 PM, Greg Von Kuster greg@bx.psu.edu wrote:

Hi Peter,

On Feb 3, 2014, at 7:01 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

Moreover there is a similar problem with the matching repository on the Test Tool Shed,

http://testtoolshed.g2.bx.psu.edu/view/peterjc/blastxml_to_top_descr 2014-01-04 showing failed tests for proteomics_search_tandem_1 2013-12-20 showing failed tests for proteomics_search_tandem_1 2013-12-18 tests for blastxml_to_top_descr passed 2013-12-17 tests for blastxml_to_top_descr passed

Like the same repository on the main tool shed, the above issue were fixed for the blastxml_to_top_descr on the test tool shed in https://bitbucket.org/galaxy/galaxy-central/commits/e3a4d4d813fdb8a34cfd6d59...

Great, thanks.

--

Returning to the MIRA4 problem, I got a meaningful test failure which I fixed (I hadn't set an environment variable in the install script), but I now get only partial test output:

http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler ... That's all fine, but where are the test results for mira_bait which I would expect to pass?

It looks lie the mira_bait tests results are being populated, bu

the tests are failing, not passing. This doesn't look like an

issue with the Tool Shed's install and test framework.

Confirmed - the Tool Shed issue where only partial test output was shown is fixed (did you work out why the test output was missing?).

I was hoping to see a passing test, but I can now see a failing test (still something not quite right with my dependency installation script - I'll look at this next week hopefully).

Thanks,

Peter

Hi Peter,

It looks like you made some changes to your tool dependency recipe since the last test run. Dave B and I followed the latest revision of your recipe and manually installed it using https://downloads.sourceforge.net/project/mira-assembler/MIRA/stable/mira_4.... and it looked ok. Let's see what the restults of tonight's test run is for this repository and if there are still problems after your latest changes we'll track them down.

Thanks,

Greg Von Kuster

On Feb 17, 2014, at 6:15 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Sat, Feb 15, 2014 at 12:32 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

On Sat, Feb 15, 2014 at 12:25 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

On Feb 3, 2014, at 7:01 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

Returning to the MIRA4 problem, I got a meaningful test failure which I fixed (I hadn't set an environment variable in the install script), but I now get only partial test output:

http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler ...

That's all fine, but where are the test results for mira_bait which I would expect to pass?

It looks lie the mira_bait tests results are being populated, but the tests are failing, not passing. This doesn't look like an issue with the Tool Shed's install and test framework.

Confirmed - the Tool Shed issue where only partial test output was shown is fixed (did you work out why the test output was missing?).

I was hoping to see a passing test, but I can now see a failing test (still something not quite right with my dependency installation script - I'll look at this next week hopefully).

Hi Greg,

I added a little more debug information to the mirabait test, which confirms a problem in the tool_dependencies.xml file:

Missing mirabait under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/7fcabeeca5df/mirabait' Folder contained: env.sh

i.e. $MIRA4 was set to $INSTALL_DIR which is the folder /ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/7fcabeeca5df/ and (surprisingly) it only contains one file, env.sh

Greg: Could you confirm that on the server? i.e. what does this give?

$ ls -l /ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/7fcabeeca5df/ ...

Upon downloading mira_4.0_linux-gnu_x86_64_static.tar.bz2 and decompressing it, the tool shed should have changed into the main folder mira_4.0_linux-gnu_x86_64_static and then moved the contents of the bin folder into the $INSTALL_DIR,

               <action

type="download_by_url">https://downloads.sourceforge.net/project/mira-assembler/MIRA/stable/mira_4....</action> <action type="move_directory_files"> <source_directory>bin</source_directory>

<destination_directory>$INSTALL_DIR</destination_directory> </action>

i.e. Move files mira, mirabait, miraconvert and miramem into $INSTALL_DIR

I am somewhat puzzled - other tools like the BLAST+ installers use a very similar setup and work fine (although there I used $PATH instead).

Thanks,

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/

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

On Mon, Feb 17, 2014 at 3:08 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Mon, Feb 17, 2014 at 2:57 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Hi Peter,

It looks like you made some changes to your tool dependency recipe since the last test run.

Yeah, the mira de novo test was missing the test-data input files. But I didn't touch mirabait or the install XML instructions.

...

Dave B and I followed the latest revision of your recipe and manually installed it using https://downloads.sourceforge.net/project/mira-assembler/MIRA/stable/mira_4.... and it looked ok.

If you mean you installed it via the Tool Shed, and it worked - that's good :)

(Or did you mean manually by running wget, tar, etc, by hand?)

...

Let's see what the restults of tonight's test run is for this repository and if there are still problems after your latest changes we'll track them down.

Sure - fingers crossed,

Hi Greg, Dave,

RE: http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler

Same as before, although now both the mirabait and mira de novo tests are attempted:

Missing mirabait under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/mirabait' Folder contained: env.sh

Missing mira under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/mira' Folder contained: env.sh

My Python wrapper checks the $MIRA4 environment variable, which should be the $INSTALL_DIR location which should hold the MIRA binaries (mira, mirabait, etc). According to the Python wrapper, the $MIRA variable was set to:

/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/

However, the Python wrapper reports this folder only contains one file, env.sh - which leads me to suspect a glitch in my tool_dependencies.xml and/or the installation framework.

Regards,

Peter

On Tue, Feb 18, 2014 at 11:41 AM, Greg Von Kuster greg@bx.psu.edu wrote:

Hi Peter,

We'll try to get some time to look at your tool_dependencies.xml recipe as soon as possible.

Greg Von Kuster

Great.

Re: https://trello.com/c/HVGrShnC/60-tool-shed-should-test-installation-of-packa...

Additional actions like asserting a file or folder exists would be good, e.g. here I would like to add something like this to the install XML script:

assert file exists $MIRA4/mira assert file exists $MIRA4/mirabait

Should I file a new Trello card for this and similar post-install checks like the Biopython example:

python -c "import Bio; assert Bio.__version__=='1.62'"

Thanks,

Peter

Hello Peter, Please see below…

On Feb 19, 2014, at 4:41 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

Hi Greg,

Overnight this has gone back to the previously observed missing data problem (e.g. email of 4th Feb) - no test results at all: http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler

Test runs 2014-02-18 16:15:52 Automated test environment Time tested: 2014-02-18 16:15:52 System: Architecture: Python version: Galaxy revision: Galaxy database version: Tool shed revision: 12485:64e6873c8825 Tool shed database version: 22 Tool shed mercurial version: 2.2.3 Tools missing tests or test data Tool id: mira_4_0_mapping Tool version: 0.0.2 Tool guid: testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_mapping/0.0.2 Missing components: Functional test definitions missing for mira_4_0_mapping.

i.e. No test successes or failures reported. Collapsing the sections a bit:

Test runs

• 2014-02-18 16:15:52 *Automated test environment

This was on Firefox (logged in, or logged out of the Tool Shed). Oddly, switching to Safari (not logged into the Tool Shed) on the same machine, or Chrome on a second machine, I also see an older test run's information where there is test output:

Test runs

• 2014-02-18 16:15:52 *Automated test environment
  • Tools missing tests or test data
• 2014-02-18 03:40:12
  • Automated test environment
  • Tests that failed
  • Tools missing tests or test data
  • Successful installation

Might some strange cache or Firefox issue be hiding data?

Your above email arrived in my inbox at 4:42 AM EST, and it looks like your repository in question was not yet tested. Using Firefox, I see the following resutls for today's test run, the results of which were updated in your Tool Shed repository at 4:50 AM EST. The nightly Install and Test Framework is finishing at about 8:00 AM EST for hte Test Tool Shed. The runs finish for the Main Tool Shed at about 5:00 AM EST.

Test runs 2014-02-19 04:50:21 Automated test environment Time tested: 2014-02-19 04:50:21 System: Linux 3.8.0-30-generic Architecture: x86_64 Python version: 2.7.4 Galaxy revision: 12536:c85f8fb5d63e Galaxy database version: 118 Tool shed revision: 12485:64e6873c8825 Tool shed database version: 22 Tool shed mercurial version: 2.2.3 Tests that failed Tool id: mira_4_0_bait Tool version: mira_4_0_bait Test: test_tool_000000 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1) Stderr: Fatal error: Exit code 1 () Missing mirabait under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/mirabait' Folder contained: env.sh Traceback: Traceback (most recent call last): File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 106, in test_tool self.do_it( td ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 34, in do_it self._verify_outputs( testdef, test_history, shed_tool_id, data_list, galaxy_interactor ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 67, in _verify_outputs galaxy_interactor.verify_output( history, output_data, outfile, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py", line 312, in verify_output self.twill_test_case.verify_dataset_correctness( outfile, hid=hid, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 827, in verify_dataset_correctness self._assert_dataset_state( elem, 'ok' ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 641, in _assert_dataset_state raise AssertionError( errmsg ) AssertionError: Expecting dataset state 'ok', but state is 'error'. Dataset blurb: error Tool id: mira_4_0_bait Tool version: mira_4_0_bait Test: test_tool_000001 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1) Stderr: Fatal error: Exit code 1 () Missing mirabait under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/mirabait' Folder contained: env.sh Traceback: Traceback (most recent call last): File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 106, in test_tool self.do_it( td ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 34, in do_it self._verify_outputs( testdef, test_history, shed_tool_id, data_list, galaxy_interactor ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 67, in _verify_outputs galaxy_interactor.verify_output( history, output_data, outfile, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py", line 312, in verify_output self.twill_test_case.verify_dataset_correctness( outfile, hid=hid, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 827, in verify_dataset_correctness self._assert_dataset_state( elem, 'ok' ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 641, in _assert_dataset_state raise AssertionError( errmsg ) AssertionError: Expecting dataset state 'ok', but state is 'error'. Dataset blurb: error Tool id: mira_4_0_bait Tool version: mira_4_0_bait Test: test_tool_000002 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1) Stderr: Fatal error: Exit code 1 () Missing mirabait under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/mirabait' Folder contained: env.sh Traceback: Traceback (most recent call last): File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 106, in test_tool self.do_it( td ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 34, in do_it self._verify_outputs( testdef, test_history, shed_tool_id, data_list, galaxy_interactor ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 67, in _verify_outputs galaxy_interactor.verify_output( history, output_data, outfile, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py", line 312, in verify_output self.twill_test_case.verify_dataset_correctness( outfile, hid=hid, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 827, in verify_dataset_correctness self._assert_dataset_state( elem, 'ok' ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 641, in _assert_dataset_state raise AssertionError( errmsg ) AssertionError: Expecting dataset state 'ok', but state is 'error'. Dataset blurb: error Tool id: mira_4_0_de_novo Tool version: mira_4_0_de_novo Test: test_tool_000000 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_de_novo/0.0.2) Stderr: Fatal error: Exit code 1 () Missing mira under $MIRA4, '/ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40/mira' Folder contained: env.sh Traceback: Traceback (most recent call last): File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 106, in test_tool self.do_it( td ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 34, in do_it self._verify_outputs( testdef, test_history, shed_tool_id, data_list, galaxy_interactor ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/functional/test_toolbox.py", line 67, in _verify_outputs galaxy_interactor.verify_output( history, output_data, outfile, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/interactor.py", line 312, in verify_output self.twill_test_case.verify_dataset_correctness( outfile, hid=hid, attributes=attributes, shed_tool_id=shed_tool_id, maxseconds=maxseconds ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 827, in verify_dataset_correctness self._assert_dataset_state( elem, 'ok' ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/base/twilltestcase.py", line 641, in _assert_dataset_state raise AssertionError( errmsg ) AssertionError: Expecting dataset state 'ok', but state is 'error'. Dataset blurb: error Tools missing tests or test data Tool id: mira_4_0_mapping Tool version: 0.0.2 Tool guid: testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_mapping/0.0.2 Missing components: Functional test definitions missing for mira_4_0_mapping. Successful installations Repository dependencies - installation of these additional repositories is required Tool shed Name Owner Changeset revision testtoolshed.g2.bx.psu.edu package_samtools_0_1_19 iuc 54195f1d4b0f Tool dependencies Type Name Version MIRA package 4.0 Installation directory /ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40 Type Name Version samtools package 0.1.19 Installation directory /ToolDepsTest/samtools/0.1.19/peterjc/mira4_assembler/133b863a8a40

Thanks,

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/

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

Hi Peter,

Dave B and I just discovered that issue that causes your tests to fail.

The problem lies with our current implementation supporting the <move_directory_files> action tag, which is used in your recipe. This tag ultimately uses Python's os.listdir via shutil.move.

It turns out that certain Python versions produce different results from os.listdir - the order is different. This is a problem with MIRA because during the instlllation it is moving a directory of files where the directory includes symlinks to other files in the directory. When the symlinks are moved after the files to which they link, problems occur. Again, this behavior is intermittent depending on the Pyhton version ( and perhaps the os ).

In any case, we have a fix for out move_directory_files which Dave is now committing. So your tests should pass with tonight's run - Let's hope!

Thanks Peter!

Greg Von Kuster

On Feb 19, 2014, at 3:49 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Wed, Feb 19, 2014 at 8:42 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Hello Peter, Please see below...

...

Your above email arrived in my inbox at 4:42 AM EST, and it looks like your repository in question was not yet tested.

Ah. That would partly explain things - perhaps coupled with a cache effect it might even explain why different browsers seemed to give me different output....

Could Galaxy include the time zone (EST) in the Tool Shed test time stamps and/or show GMT/UTC? (You have no easy way of knowing the user's local timezone do you?).

Alternatively, "Test in progress" would be nice :)

As to the test failure, it seems $INSTALL_DIR or at least $MIRA4 only contains env.sh (which puzzles me).

Thanks,

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/

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

Hi Peter,

On Feb 19, 2014, at 6:09 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Wed, Feb 19, 2014 at 9:33 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Hi Peter,

Dave B and I just discovered that issue that causes your tests to fail.

The problem lies with our current implementation supporting the <move_directory_files> action tag, which is used in your recipe. This tag ultimately uses Python's os.listdir via shutil.move.

It turns out that certain Python versions produce different results from os.listdir - the order is different. This is a problem with MIRA because during the instlllation it is moving a directory of files where the directory includes symlinks to other files in the directory. When the symlinks are moved after the files to which they link, problems occur. Again, this behavior is intermittent depending on the Pyhton version ( and perhaps the os ).

In any case, we have a fix for out move_directory_files which Dave is now committing. So your tests should pass with tonight's run - Let's hope!

Thanks Peter!

Well done Greg & Dave,

That explanation makes perfect sense to me - but I can see it took some digging to solve it!

There is actually one MIRA binary (mira) and several aliases (e.g. mirabait) which are really symlinks back to mira. Magic.

My next query would be: why wasn't the failing action <move_directory_files> being caught as a failed install?

Your installation recipe for mira attempts to download a binary and if that fails, it echoes an error, but still performs <set_environment> actions..

The tool dependency installation process will fall back to attempting the installation using the action tags to handle install from source and compile if downloading a pre-compiled binary fails. However, your recipe does not have include installing from source, so the installation process simply assumed your <set_environment> tags were all that was necessary. If the recipe for installing from source is not too complex, maybe you could add it to your recipe. It's probabluy not critical though since we now have the fix to the framework.

Here is the entire log of the installtion process that helped us uncover the problem - notice that upon failure of the initial binary installation, the process "proceeds with install and compile recipe for tool dependency MIRA".

tool_shed.galaxy_install.tool_dependencies.fabric_util DEBUG 2014-02-19 04:50:42,285 Successfully downloaded from url: https://downloads.sourceforge.net/project/mira-assembler/MIRA/stable/mira_4.... tool_shed.galaxy_install.tool_dependencies.install_util ERROR 2014-02-19 04:50:42,318 Error installing tool dependency MIRA version 4.0. Traceback (most recent call last): File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/install_util.py", line 289, in install_and_build_package_via_fabric tool_dependency = fabric_util.install_and_build_package( app, tool_dependency, actions_dict ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py", line 581, in install_and_build_package destination_dir=os.path.join( action_dict[ 'destination_directory' ] ) ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/td_common_util.py", line 309, in move_directory_files shutil.move( source_file, destination_file ) File "/usr/lib/python2.7/shutil.py", line 301, in move copy2(src, real_dst) File "/usr/lib/python2.7/shutil.py", line 130, in copy2 copyfile(src, dst) File "/usr/lib/python2.7/shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc: IOError: [Errno 2] No such file or directory: '/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/install_and_test_tool_shed_repositories/repositories_with_tools/tmp/tmpdr4lDp/tmp-toolshed-mtdV8W9PM/mira_4.0_linux-gnu_x86_64_static/bin/mirabait' tool_shed.galaxy_install.tool_dependencies.install_util DEBUG 2014-02-19 04:50:42,541 Error downloading binary for tool dependency MIRA version 4.0: File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/install_util.py", line 289, in install_and_build_package_via_fabric tool_dependency = fabric_util.install_and_build_package( app, tool_dependency, actions_dict ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py", line 581, in install_and_build_package destination_dir=os.path.join( action_dict[ 'destination_directory' ] ) ) File "/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/td_common_util.py", line 309, in move_directory_files shutil.move( source_file, destination_file ) File "/usr/lib/python2.7/shutil.py", line 301, in move copy2(src, real_dst) File "/usr/lib/python2.7/shutil.py", line 130, in copy2 copyfile(src, dst) File "/usr/lib/python2.7/shutil.py", line 82, in copyfile with open(src, 'rb') as fsrc:

[Errno 2] No such file or directory: '/var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/test/install_and_test_tool_shed_repositories/repositories_with_tools/tmp/tmpdr4lDp/tmp-toolshed-mtdV8W9PM/mira_4.0_linux-gnu_x86_64_static/bin/mirabait' tool_shed.galaxy_install.tool_dependencies.install_util DEBUG 2014-02-19 04:50:42,541 Proceeding with install and compile recipe for tool dependency MIRA. tool_shed.util.tool_dependency_util DEBUG 2014-02-19 04:50:42,549 Removed tool dependency installation directory: /ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40 /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py:173: DeprecationWarning: With-statements now directly support multiple context managers with settings( warn_only=True ): /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py:646: DeprecationWarning: With-statements now directly support multiple context managers with settings( warn_only=True ): /var/opt/buildslaves/buildslave-ec2-2/buildbot-install-test-test-tool-shed-py27/build/lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py:173: DeprecationWarning: With-statements now directly support multiple context managers with settings( warn_only=True ):

Warning: local() encountered an error (return code 2) while executing 'echo Your machine details (the output from 'uname' and 'arch'):'

tool_shed.galaxy_install.tool_dependencies.install_util DEBUG 2014-02-19 04:50:43,683 Proceeding with install and compile recipe for tool dependency MIRA. tool_shed.util.tool_dependency_util DEBUG 2014-02-19 04:50:43,690 Removed tool dependency installation directory: /ToolDepsTest/MIRA/4.0/peterjc/mira4_assembler/133b863a8a40 tool_shed.util.tool_dependency_util DEBUG 2014-02-19 04:50:43,698 Changing status for tool dependency MIRA from Uninstalled to Installed.

Thanks,

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/

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

if a tool failed we all really benefit from seeing as much as we can - as securely as we can. Can we safely expose them somewhere protected?

On Thu, Feb 20, 2014 at 8:59 PM, Peter Cock p.j.a.cock@googlemail.comwrote:

,

On Thu, Feb 20, 2014 at 2:56 AM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Hi Peter,

On Wed, Feb 19, 2014 at 9:33 PM, Greg Von Kuster greg@bx.psu.edu

wrote:

...

...

...

In any case, we have a fix for out move_directory_files which Dave is now committing. So your tests should pass with tonight's run - Let's hope!

That explanation makes perfect sense to me - but I can see it took some digging to solve it!

There is actually one MIRA binary (mira) and several aliases (e.g. mirabait) which are really symlinks back to mira. Magic.

For anyone interested, the fix was this commit:

https://bitbucket.org/galaxy/galaxy-central/commits/a89bbdfd4a71671d575d9a0a...

...

...

My next query would be: why wasn't the failing action <move_directory_files> being caught as a failed install?

Scanning over the code, some of the actions have explicit error handling but make_directory, move_directory_files, move_file and others do not. I guess any exception is propagated up... lib/tool_shed/galaxy_install/tool_dependencies/fabric_util.py

...

Your installation recipe for mira attempts to download a binary and if

that

...

fails, it echoes an error, but still performs <set_environment> actions..

Ah - I can see that now, I need a fall back <action> tag which either tries to compile MIRA or raises an explicit error. Thanks!

...

Here is the entire log of the installtion process that helped us uncover

the

...

problem - notice that upon failure of the initial binary installation,

the

...

process "proceeds with install and compile recipe for tool dependency

MIRA".

Would it be a security risk to automatically expose these logs?

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/

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

Hi Peter,

Regarding youyr previous question about why the more usefule log resutls are not returned for display in the Tool Shed, the reason is that our use of fabric's local command for installing tool dependnecies restricts us from bewing able to capture that information. We are currently working to eliminate the use of fabric for tool dependency installations - the Trello card is here:

https://trello.com/c/zJoRROvv/147-eliminate-the-use-of-fabric-as-the-install...

We should have this workling this week, after which better error logs can be treurned to the Tool Shed and several other Terello cards can be handled.

See my inline comments below…

On Feb 20, 2014, at 5:30 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Thu, Feb 20, 2014 at 9:59 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

On Thu, Feb 20, 2014 at 2:56 AM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Your installation recipe for mira attempts to download a binary and if that fails, it echoes an error, but still performs <set_environment> actions..

Ah - I can see that now, I need a fall back <action> tag which either tries to compile MIRA or raises an explicit error. Thanks!

Sorry, slightly confused: there was a fallback <action> tag which was and is meant to raise an error. It was accidentally raising an error due to a bash syntax error in my unquoted echo (which that detailed log you posted alerted me to), now fixed in my repository and uploaded to the Test Tool Shed: https://github.com/peterjc/pico_galaxy/commit/4b003cf9b5e6baa15c75bb65723c5a... http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler

The BLAST+ packages have the same glitch in their fall-back (so I will need to update them on the main and test Tool Shed, although I will delay that pending your reply to the problem below): https://github.com/peterjc/galaxy_blast/commit/4b2fa1fbf485c4630cb6dc0beaf72...

So, what happens is first the arch/os specific actions is tried, here

<actions os="linux" architecture="x86_64">

That was failing with MIRA4 due to the symlink bug (now fixed). Because the platform specific action failed, the generic <actions> was used - where I deliberately try to raise an error to signal the installation failed.

What is surprising me is that the Tool Shed see the error, logs it, but still continues on (setting my environment variables, and reporting success). Why is that?

I'll need some time to investigate this behavior - if I discover a framework issue, I'll provide a fix.

Thanks,

Peter

P.S. The assert file exists action I suggested previously would be a neat way to catch some failing installs, e.g. here I expected the executables $MIRA4/mira and $MIRA4/mirabait etc to exist. I've filed a Trello card for this enhancement idea:

https://trello.com/c/xBUhFvj0/1446-add-assert-file-exists-and-directory-exis...

Thanks - I've moved it to the Tool Shed Trello Board - its in Project in Planning.

Greg Von Kuster

---

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/

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

Peter,

The test result at 13:11:20 is due to me manually running the install and test framework to test the fabric replacement code I introduced. The test result at 16:16:58 is due to the repository preparation script running successfully at its scheduled time, initializing the tool test results for the soon-following test run, but the install and test framework failed to run any tests due to a missing import in 12566:01a572fb8b4c. I've committed a fix for that issue now, and this evening's test run should return proper results.

--Dave B.

On 02/21/2014 04:37 AM, Peter Cock wrote:

Hi Greg & Dave,

Now that moving symlinks has been fixed, something new happened on the MIRA4 tests yesterday: http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler

It seems one test run has been split in two - the early section at 13:11:20 includes the tests run for mira_4_0_de_novo and mira_4_0_bait (which passed - yay), while the later section at 16:16:58 reported that mira_4_0_mapping has no tests (true for now).

Peter

--

Automated tool test results

Test runs 2014-02-20 16:16:58 Automated test environment Tools missing tests or test data *Tool id:* mira_4_0_mapping *Tool version:* 0.0.2 *Tool guid:* testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_mapping/0.0.2 http://testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_mapping/0.0.2

*Missing components:* Functional test definitions missing for mira_4_0_mapping.

2014-02-20 13:11:20 Automated test environment Tests that passed successfully *Tool id:* mira_4_0_bait *Tool version:* mira_4_0_bait *Test:* test_tool_000000 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1 http://functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1)

*Tool id:* mira_4_0_bait *Tool version:* mira_4_0_bait *Test:* test_tool_000001 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1 http://functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1)

*Tool id:* mira_4_0_bait *Tool version:* mira_4_0_bait *Test:* test_tool_000002 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1 http://functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_bait/0.0.1)

*Tool id:* mira_4_0_de_novo *Tool version:* mira_4_0_de_novo *Test:* test_tool_000000 (functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_de_novo/0.0.2 http://functional.test_toolbox.TestForTool_testtoolshed.g2.bx.psu.edu/repos/peterjc/mira4_assembler/mira_4_0_de_novo/0.0.2)

Successful installations Repository dependencies/- installation of these additional repositories is required/ Tool dependencies

---

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/

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

Hello Peter,

On Feb 20, 2014, at 10:20 AM, Greg Von Kuster greg@bx.psu.edu wrote:

...

On Thu, Feb 20, 2014 at 9:59 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

On Thu, Feb 20, 2014 at 2:56 AM, Greg Von Kuster greg@bx.psu.edu wrote:

...

Your installation recipe for mira attempts to download a binary and if that fails, it echoes an error, but still performs <set_environment> actions..

Ah - I can see that now, I need a fall back <action> tag which either tries to compile MIRA or raises an explicit error. Thanks!

Sorry, slightly confused: there was a fallback <action> tag which was and is meant to raise an error. It was accidentally raising an error due to a bash syntax error in my unquoted echo (which that detailed log you posted alerted me to), now fixed in my repository and uploaded to the Test Tool Shed: https://github.com/peterjc/pico_galaxy/commit/4b003cf9b5e6baa15c75bb65723c5a... http://testtoolshed.g2.bx.psu.edu/view/peterjc/mira4_assembler

The BLAST+ packages have the same glitch in their fall-back (so I will need to update them on the main and test Tool Shed, although I will delay that pending your reply to the problem below): https://github.com/peterjc/galaxy_blast/commit/4b2fa1fbf485c4630cb6dc0beaf72...

So, what happens is first the arch/os specific actions is tried, here

<actions os="linux" architecture="x86_64">

That was failing with MIRA4 due to the symlink bug (now fixed). Because the platform specific action failed, the generic <actions> was used - where I deliberately try to raise an error to signal the installation failed.

What is surprising me is that the Tool Shed see the error, logs it, but still continues on (setting my environment variables, and reporting success). Why is that?

I'll need some time to investigate this behavior - if I discover a framework issue, I'll provide a fix.

The above issue should be corrected in https://bitbucket.org/galaxy/galaxy-central/commits/f5a119ac52a957204ab968a7... which is currently running on the Test Tool Shed. I'm going to wait for tonight's Install and Test run on the Test Tool Shed to make sure all is well with the fix. If things look good we'll graft the fix to the stable branch tomorrow. Thanks for reporting this!

As we briefly discussed earlier, your mira4 recipe is not currently following best practices. Although you uncovered a problem in the framework which has now been corrected, your recipe's fall back <actions> tag set should be the recipe for installing mira4 from source ( http://sourceforge.net/projects/mira-assembler/ ) since there is no licensing issues for doing so. This would be a more ideal approach than echoing the error messages.

Thanks very much for helping us discover this problem though!

Greg Von Kuster

...

Thanks,

Peter

P.S. The assert file exists action I suggested previously would be a neat way to catch some failing installs, e.g. here I expected the executables $MIRA4/mira and $MIRA4/mirabait etc to exist. I've filed a Trello card for this enhancement idea:

https://trello.com/c/xBUhFvj0/1446-add-assert-file-exists-and-directory-exis...

Thanks - I've moved it to the Tool Shed Trello Board - its in Project in Planning.

Greg Von Kuster

...

---

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/

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: http://lists.bx.psu.edu/

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

On Thu, Mar 6, 2014 at 5:24 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

On Thu, Mar 6, 2014 at 4:53 PM, Greg Von Kuster greg@bx.psu.edu wrote:

...

On Feb 20, 2014, at 10:20 AM, Greg Von Kuster greg@bx.psu.edu wrote:

...

...

On Thu, Feb 20, 2014 at 9:59 AM, Peter Cock p.j.a.cock@googlemail.com wrote:

...

So, what happens is first the arch/os specific actions is tried, here

<actions os="linux" architecture="x86_64">

That was failing with MIRA4 due to the symlink bug (now fixed). Because the platform specific action failed, the generic <actions> was used - where I deliberately try to raise an error to signal the installation failed.

What is surprising me is that the Tool Shed see the error, logs it, but still continues on (setting my environment variables, and reporting success). Why is that?

I'll need some time to investigate this behavior - if I discover a framework issue, I'll provide a fix.

The above issue should be corrected in https://bitbucket.org/galaxy/galaxy-central/commits/f5a119ac52a957204ab968a7... which is currently running on the Test Tool Shed. I'm going to wait for tonight's Install and Test run on the Test Tool Shed to make sure all is well with the fix. If things look good we'll graft the fix to the stable branch tomorrow. Thanks for reporting this!

...

Hi Greg,

No problem - I'm good at discovering problems ;)

If the download approach failed, it it most likely due to a transient error (e.g. network issues with download). Here I would much prefer Galaxy aborted and reported this as an error (and does not attempt the default action). Is that what you just fixed?

Re-reading the commit, and in particular the comment, it sounds like you have not fixed the larger issue I am trying to flag, quoting the commit comment:

...

Fixes to handle case where a tool dependency recipe defines an <actions_group> tag set for installing pre-compiled binaries which fail to install, so the fall back recipe for installing and compileing from souce is used. Prior to this change set, the recipe from source would not work, but the install process would finish in such a way that the recipe seemed to work.

i.e. The fall back action in my MIRA4 and BLAST+ recipes where I use "false" to raise an error should now be treated as an error (rather than as before being a silent failure). That's progress :)

Given the current behaviour of switching to the default action if the platform specific action fails (which I think is unwise), does the Tool Shed clean up the failed platform specific installation before attempting the default action? e.g. The failed action may have downloaded and unzipped some files which could interfere.

Thanks,

Peter