- 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 (galaxyproject#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.

Add a new profile database type option "postgres_docker". The existing "postgres" type option expects a local database to be accessible via the "psql" command on Planemo's PATH - probably few people have postgres running directly on their development machine and fewer still have it configured to allow passwordless entry. This newer variant is a much simpler interface - it starts a named container for the official Docker postgres image and uses that to manage the profile. This should make using profiles easier for most developers.

This new modality does have some shortcomings - it should probably be redone to persist the database somewhere -or- start and stop the same container (currently when the container is stopped the data is gone).

This also updates the workflow test that encounters Galaxy locks to pickup the environment variable PLANEMO_TEST_WORKFLOW_RUN_PROFILE and PLANEMO_TEST_WORKFLOW_RUN_PROFILE_DATABASE_TYPE and use these to create and use a profile during testing if set as well as setting that variable in Travis to leverage the postgres service already configured for other tests. This more less fixes what I had in mind with galaxyproject#772 but it would be nice to leverage galaxyproject/galaxy#4887 for greater test isolation.

Add a new profile database type option "postgres_docker". The existing "postgres" type option expects a local database to be accessible via the "psql" command on Planemo's PATH - probably few people have postgres running directly on their development machine and fewer still have it configured to allow passwordless entry. This newer variant is a much simpler interface - it starts a named container for the official Docker postgres image and uses that to manage the profile. This should make using profiles easier for most developers.

This new modality does have some shortcomings - it should probably be redone to persist the database somewhere -or- start and stop the same container (currently when the container is stopped the data is gone).

This also updates the workflow test that encounters Galaxy locks to pickup the environment variable PLANEMO_TEST_WORKFLOW_RUN_PROFILE and PLANEMO_TEST_WORKFLOW_RUN_PROFILE_DATABASE_TYPE and use these to create and use a profile during testing if set as well as setting that variable in Travis to leverage the postgres service already configured for other tests. This more less fixes what I had in mind with galaxyproject#772 but it would be nice to leverage galaxyproject/galaxy#4887 for greater test isolation.