Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Lighter weight Selenium test setup for PRs. #4925
The Dockerfile and image update in #4900 baked chrome, chrome-wrapper, xvfb, and a Selenium server into the default Galaxy testing image. This means we should no longer need to run three docker containers in a compose setup to run Selenium tests. This swaps the script target used by Jenkins to use this newer variant of the tests.
In addition to simply consuming less CPU and booting up much faster thanks to pre-installed dependencies and pre-migrated database, this setup is much easier to cleanup and so we don't need to restrict it to one test per host - these tests I think should run just like API and framework tests. This should also be easier for people running tests locally - this is probably now by far the easiest way to run these tests on Mac or Linux (non-Dockerized test setups are still faster once you get them setup - but it is non-trivial for Mac at least).
I've kept the old compose setup around and I'll setup a Jenkins job against dev that continues to run it periodically (just not on PRs). It does testing of proxy prefix things this variant doesn't and serves as a good reference implementation for multi-container Galaxy testing - which we may wish to do for various categories of tests in the future. The multi-container variant makes it much easier to bring in various services - lots of which one can imagine writing useful Galaxy tests for - AMQP, statistics collection, Docker itself, etc....
@jmchilton Tried to run this locally and everything looks like it's working until "Waiting on service postgres", which hangs forever. I'm probably just testing it wrong, but just to check, how should I execute this and other than a running Docker, do I need anything else?
Tried running both versions; I just pasted the wrong error, sorry!
The non-compose error was something like:
So do I need to set up special mounts for this?
@dannon I see - yeah you can't mount in your temp directory because it isn't available inside your Docker host's VM. I'm guessing you can't run any of the Docker CI scripts.
You can probably run:
from Galaxy's root though I'd guess... that gets you close and avoids the tmp directory hacking we use on our Jenkins server to reduce the frequency of those "text file is busy" errors.
The .ci script in that folder just runs almost the same command as that but includes this argument
If you want to hack your Mac to do that - it is pretty easy though:
I've had to mount the
I guess I don't really recommend running the script