- Bake Selenium (chrome, chrome-wrapper, xvfb, and Selenium server) into Docker test image. (1)
- Correct usage of common_startup.sh to fetch dev wheels (don't use pip directly).
- Fix/enhance the test wrapper file to not set GALAXY_CONFIG_OVERRIDE_DATABASE_CONNECATION - this prevents integration database templating (#4887) from working with the Docker image.
- Update target Dockerfile.
1) The Docker compose setup for Selenium tests currently used by Jenkins is nice in that it uses official Selenium and Postgres Docker images - but it is problematic in that it takes more resources than the other single container Docker jobs, it doesn't cleanup as nicely, it doesn't have a pre-migrated database or pre-installed dependencies so it takes longer to run, and isn't easily exposed to developers via run_tests.sh. A more pragmatic Jenkins job based on this work should be runnable for every PR - the current variant simply takes too long and requires too many resources.
- Target dev on Github instead of stable on bitbucket for base dependencies and migrations.
- Update to Ubuntu 16.04 ahead of trying to merge in Selenium support (should be a bit slimmer without the TS requirements layer also).
- Use fancy new Node compatible with yarn.
- Fix if testing as user with GID 109 (fixes#3425).
- Fix if testing as a user with any UID or GID that already exists in the container.
- More logging to indicate the "problems" being printed to standard output in these cases are not problems.
- Fix sqlite being readonly in the container for the test user.
I don't know how this ever worked to be honest - but these changes make a lot of sense. I think there was another bug somewhere that prevented this bug from exhibiting itself.
- Remove broken CasperJS from testing Dockerfile.
- Remove multi-process mode.
Multi-process mode was difficult to maintain and the last time I did testing at scale I found docker-galaxy-stable to be much more useful and easy to use. The test framework now supports GALAXY_TEST_EXTERNAL again so it should be easy enough to rig something up with docker-compose that actually uses a best practice container for scaling tests such as those in ``test/manual``.
Do this by calling common_startup.sh prior to manage_db.sh in
run_test_wrapper.sh. Will require a rebuild of the testing-base image.
Also, have scripts in Galaxy root activate .venv if it exists.
- Add script to hit the API with workflows requests.
- Update testing Dockerfile to allow just booting up with a fixed master API key for this test to leverage.
- WIP: on updating test Dockerfile to work with slurm, multiple handlers, uwsgi, etc...
Runs tests in a Dockerfile with pre-migrated databases and all testing dependencies (postgres, mysql, npm, casper, phantomjs, etc...). Hopefully this makes it easier to run more interesting tests - down the road I would like to add more options for things like condor, slurm, run as real user, etc....
John Chilton