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

Another round of Docker enhancements and fixes for 18.01. #4900

Merged
merged 2 commits into from Nov 1, 2017

Conversation

Projects
None yet
3 participants
@jmchilton
Member

jmchilton commented Oct 30, 2017

  • 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.
Another round of Selenium enhancements and fixes for 18.01.
- 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.

@galaxybot galaxybot added the triage label Oct 30, 2017

@galaxybot galaxybot added this to the 18.01 milestone Oct 30, 2017

@jmchilton jmchilton changed the title from Another round of Selenium enhancements and fixes for 18.01. to Another round of Docker enhancements and fixes for 18.01. Oct 31, 2017

@martenson

This comment has been minimized.

Member

martenson commented Nov 1, 2017

Thanks @jmchilton !

@martenson martenson merged commit 79d9181 into galaxyproject:dev Nov 1, 2017

6 checks passed

api test Build finished. 306 tests run, 4 skipped, 0 failed.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
framework test Build finished. 162 tests run, 0 skipped, 0 failed.
Details
integration test Build finished. 57 tests run, 0 skipped, 0 failed.
Details
lgtm analysis: JavaScript No alert changes
Details
toolshed test Build finished. 577 tests run, 0 skipped, 0 failed.
Details

jmchilton added a commit to jmchilton/galaxy that referenced this pull request Nov 3, 2017

Lighter weight Selenium test setup for PRs.
The Dockerfile and image update in galaxyproject#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.

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 added a commit to jmchilton/galaxy that referenced this pull request Nov 3, 2017

Lighter weight Selenium test setup for PRs.
The Dockerfile and image update in galaxyproject#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.

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 added a commit to jmchilton/galaxy that referenced this pull request Nov 3, 2017

Lighter weight Selenium test setup for PRs.
The Dockerfile and image update in galaxyproject#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.

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 added a commit to jmchilton/galaxy that referenced this pull request Nov 3, 2017

Lighter weight Selenium test setup for PRs.
The Dockerfile and image update in galaxyproject#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.

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 added a commit to jmchilton/galaxy that referenced this pull request Nov 3, 2017

Lighter weight Selenium test setup for PRs.
The Dockerfile and image update in galaxyproject#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.

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....
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment