New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement shed serve and test commands, other enhancements. #213

Merged
merged 6 commits into from May 19, 2015

Conversation

Projects
None yet
3 participants
@jmchilton
Copy link
Member

jmchilton commented May 18, 2015

  • Implement shed_test command that installs the latest installable revision of specified repositories and tests them. Closes #176. a48d811
  • Implement shed_serve command that likewise installs the latest installable revision of specified repositories into a fresh Galaxy instance and serves it. 74e3d64
  • Enhance a variety of commands to allow specifying multiple paths (test, serve, shed_*). Closes #150. 2bd5dfc
  • Refactorings to enable this and reduce existing duplication. daa4f59, 4116999

Requires merging of:

jmchilton added some commits May 15, 2015

Implement a ``--failed`` flag for the ``test`` command.
This will use ``tool_test_output.json`` to determine which tests failed the last time ``planemo test`` was executed and only run those previously failing tests. This should speed up test-driven development of tools.

Requires galaxyproject/galaxy#266.

Closes #145.
Implement ``shed_serve`` command.
This will install the latest revision of the corresponding selected repositories from the target tool shed and serve a Galaxy instance with them installed.
Implement ``shed_test`` command.
The test command tests local copies of files, shed_test resolves repositories, find the latest installed revisions on the shed, installs these revisions in a fresh Galaxy clone, and tests them with ``./run_tests.sh -installed``.

Requires galaxyproject/galaxy#267.

Closes #176.

@jmchilton jmchilton force-pushed the jmchilton:shed_install branch from c88398f to a48d811 May 18, 2015

@erasche

This comment has been minimized.

Copy link
Member

erasche commented May 18, 2015

@jmchilton does this get us closer to #19 ?

@jmchilton

This comment has been minimized.

Copy link
Member Author

jmchilton commented May 18, 2015

Nope... this is almost exactly the opposite of that. Planemo was originally about fighting the machine and has totally devolved into just another a cog 😡.

I have been making slow progress on #19 (for instance https://github.com/galaxyproject/planemo/tree/shed2tap2). I tried to work on this again this weekend and I am having real problems synchronizing how Python is handled in the Tool Shed with Homebrew.

@erasche

This comment has been minimized.

Copy link
Member

erasche commented May 18, 2015

Ahah. Gotcha. From the description of "installs the latest installable revision of specified repositories into a fresh Galaxy instance and serves it" it sounded a lot like we'd be getting close to testing tools with dependencies.

@jmchilton

This comment has been minimized.

Copy link
Member Author

jmchilton commented May 18, 2015

This does test tools with dependencies - but once they have been uploaded into the tool shed not before. This can be thought of a stand-alone variant of Galaxy's install and test framework.

@erasche

This comment has been minimized.

Copy link
Member

erasche commented May 18, 2015

So, if I'm reading this right, I can use shed_test for testing packages, and then shed_serve to upload them all to a Galaxy, and somehow then use a test to use that same Galaxy with the installed packages?

@jmchilton

This comment has been minimized.

Copy link
Member Author

jmchilton commented May 18, 2015

Not quite - a potential workflow would be something like this:

  • Use test and lint to develop tools locally.
  • Use serve to review tool. Ready to publish...
  • Use shed_init to create .shed.yml.
  • Write tool_dependencies.xml.
  • Use shed_upload --force_repository_creation --shed_target testtoolshed to populate the tool on the test tool shed.
  • Use shed_test --target testtoolshed to test published tools. This will start a Galaxy in the background, install the tool(s) from the test tool shed and its dependencies, and run the tests with tool shed dependency resolution (instead of local resolution configured with test).
  • Publish to main tool shed.

I don't think I would use shed_serve in a typical workflow - but if you want to do serve but with tool shed installed tools instead of local copies - that is what it would do. (More for consistency and as a stepping stone to ``shed_test`.)

The goal with #19 is more to have a test that works like shed_test but without having to upload the packages to the tool shed and install and test them. If you had a really robust variant of #19 you can imagine you could eliminate publishing to the test tool shed and running shed_test from this workflow - you would be confident the thing you upload passes the tests before publishing them.

@erasche

This comment has been minimized.

Copy link
Member

erasche commented May 18, 2015

As always I'm thinking from the perspective of CI servers... :)

So I could do:

  • launch a TS in a docker container (@bgruening, we can do this yeah?)
  • Use shed_upload --force_repository_creation --shed_target $docker_ts to populate the tool on the local tool shed.
  • Use shed_test --target $docker_ts to test published tools. This will start a Galaxy in the background, install the tool(s) from the test tool shed and its dependencies, and run the tests with tool shed dependency resolution (instead of local resolution configured with test).
@jmchilton

This comment has been minimized.

Copy link
Member Author

jmchilton commented May 18, 2015

Well again - if we could do the mythical #19 you wouldn't need the tool shed - planemo+galaxy would be enough.

This stop gap is so I have something useful to show at the GCC but doesn't help with your exact scenario. It does help with other potential CI jobs - for instance you can imagine automatically pushing everything committed to github to the test tool shed and if the tests pass there with shed_test then promoting them to the main tool shed. Or giving the repository a green light for publication in a UI built on something like #177.

But yes - this doesn't help at all with testing pull requests say - without combining it with something like #119 or "capsules".

@erasche

This comment has been minimized.

Copy link
Member

erasche commented May 18, 2015

Sure, not needing a TS would be absolutely brilliant, but I'm willing to use whatever hacks/stopgaps I can in the meantime.

for instance you can imagine automatically pushing everything committed to github to the test tool shed and if the tests pass there with shed_test then promoting them to the main tool shed

definitely going to do that for galaxyproject/tools-iuc#129

I'll play around with the new commands soon and see what I can do, I really, really, really want Jenkins/Planemo tests to start being green across the board rather than "oh, this test is failing because the bedtools from brew is a different patch version than the one in the TS"

@bgruening

This comment has been minimized.

Copy link
Member

bgruening commented May 18, 2015

@erasche yes we have a TS in a docker container if you are interested.
@jmchilton probably know my plan to strip out the relevant parts of parsing & installing tool_dependencies into it's own library. But this hack is great and serves us well over the next month I guess!

Thanks John!
Bjoern

@erasche

This comment has been minimized.

Copy link
Member

erasche commented May 18, 2015

@bgruening wunderbar. I'll test this out wednesday and see if I can get jenkins to handle complete testing now. Ahhh so excited.

jmchilton added a commit that referenced this pull request May 19, 2015

Merge pull request #213 from jmchilton/shed_install
Implement shed serve and test commands, other enhancements.

@jmchilton jmchilton merged commit 5812464 into galaxyproject:master May 19, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jmchilton jmchilton deleted the jmchilton:shed_install branch May 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment