On Tue, Jul 22, 2014 at 1:15 PM, Eric Rasche <rasche.eric@yandex.ru> wrote:
Hi Peter,
On July 22, 2014 3:15:41 AM CDT, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Given how close you can get now for minimal effort, this seem unnecessary.
http://blastedbio.blogspot.co.uk/2013/09/using-travis-ci-for-testing-galaxy-...
My TravisCI setup this fetches the latest Galaxy as a tar ball (from a GitHub mirror as it was faster than a git clone which was faster than getting the tar ball from BitBucket, which in turn was faster than using hg clone),
Yes, that post was at least part of the thinking behind this.
:)
.., and a per-migrated SQLite database (using a bit of Galaxy functionality originally with $GALAXY_TEST_DB_TEMPLATE added to speed up running the functional tests).
Apologies for grammatical error - I pasted in the environment variable at the wrong point in the sentence.
I know I've seen that used but was never able to get that working in practice (then again I didn't try that hard). If that's a working/usable feature, then that is already the majority of setup time.
Yes, the creation of the test-database and all the migrations was an obvious low-hanging fruit when we were looking at making running the tool functional tests faster - although originally in the context of running the tests on a local development Galaxy instance. As to using this in practise, currently my TravisCI setup has: export GALAXY_TEST_DB_TEMPLATE=https://github.com/jmchilton/galaxy-downloads/raw/master/db_gx_rev_0117.sqli... I also added that line at the start of my local copy of script run_functional_tests.sh to benefit from this while doing development. That should be all there is to it (but from memory, this is only for use with the SQLite backend). John - could you add a current schema snapshot to https://github.com/jmchilton/galaxy-downloads/ please?
Note this does not cache the eggs and all the other side effects of the first run like creating config files, so there is room for some speed up.
Eggs would be nice but not the biggest thing in the world.
Right. I do like your idea of automatically generated cutting-edge or each stable release Docker images though (even if I have no personal need for them at the moment). Regards, Peter