The unit tests expect the user to be vitess, however that has a
negative impact on our ability to build the software inside the
containers. This specifically requires the user to be vitess for
testing
Signed-off-by: DK <dk@planetscale.com>
This test was broken on newer Docker versions. According to https://serverfault.com/questions/824809/chrome-under-docker-cap-sys-admin-vs-privileged probably since Docker 1.12.
Note that Travis CI uses a different mechanism to run this test and
therefore the test always passed there.
However, project maintainers who followed
https://github.com/vitessio/vitess/tree/master/docker/bootstrap#for-vitess-project-maintainers
to update (and test!) the bootstrap images should have seen this error.
Note that I have extended test/environment.py. It now configures
webdriver to let chromedriver always log everything. If Chrome does not
start, the test will print the chromedriver log file. This is how I
found out why Chrome did not come up.
Also note that I saw some flaky test invocations. I hope that turning on
the logging in chromedriver does not result into timing issues and more
flaky tests. If so, we should consider to fix the tests and make them
more robust.
Signed-off-by: Michael Berlin <mberlin@google.com>
This will fix the recent test failures and undo the change from https://github.com/youtube/vitess/issues/3203 where we had to disable the tests "unit" and "mysql_server" because they were constantly failing. With this change, the two tests are enabled again.
More importantly, with this change we no longer have to maintain Vitess' dependencies in the Travis CI environment.
Instead, we'll depend on our "bootstrap" Docker images to run the test.
Note that I had to come up with a caching mechanism for "make build". By default, we provide the test within the Docker container with a clean copy of the Git repository and run "make build" before *each* test i.e. a Travis build with 10 tests in it would have run "make build" 10 times. To avoid this, I added a new option "-use_docker_cache" to test.go which will run "make build" before all tests and use "docker commit" to create a new temporary cache image.
Overall, this change has several consequences:
- Travis CI builds will be dependent on an up to date Docker image. For example, if somebody adds a dependency to vendor/vendor.json and forgets to rebuild and push the used Docker image, "make build" will fail. I'll add a test for this in a separate commit.
- We'll use MySQL 5.7 (instead of MariaDB) for the Travis test runs.
- We can no longer use Travis container infrastructure and have to use the VM infrastructure instead. That means an additional 20 seconds wait time until Travis has started a VM and runs the build.
- More overhead per Travis build because we need to pull the Docker image first (takes up to two minutes). Before, we used Travis' caching mechanism to cache dependencies between builds.
- Slightly slower tests because the VM infrastructure has less resources than the container one (~2 CPUs (bursted) instead of 2 CPUs, see https://docs.travis-ci.com/user/reference/overview/).
- The ".git" directory will be copied into the Docker image as well now because travis/check_make_proto.sh needs it. I'll create a separate commit to integrate this.
Please refer to #2694 and #2670 for motivation and reasoning for
this change.
I've tried to follow best practice in inserting the copyright
headers. In other open source projects, not all files carry
the notice. For example documentation doesn't. I've followed
similar ground rules.
I did not change the php because there is a separate LICENSE
file there by Pixel Federation. We'll first need to notify
them our intent before changing anything there.
As for the presubmit check, it's going to be non-trivial
because of the number of exceptions, like file types,
directories and generated code. So, it will have to be
a separate project.
Previously, the permissions of all items *within* the repository were already updated, but not the repository itself.
This resulted into the error 'cp: cannot stat `/tmp/src/*': Permission denied' when running "docker/test/run.sh mariadb".
Otherwise, you may get permission denied when trying to remove the temp
dir as a normal user, because the files were created by the 'vitess'
user inside Docker.
This is an alternative to 'make integration_test',
with the following advantages:
* Tests run in Docker, so no bootstrap is necessary.
* Tests are hermetic and can run in parallel.
* Test against different flavors just by setting a flag.
* Failing tests are retried to see if they are flaky.
* A failed test will be recorded for later inspection, while the script
continues to run other tests.
* A test that takes too long will be considered stuck and retried.
There's plenty of room for improvement, but now that we have something
in a more readable language than Makefile, we can iterate.
This will let contributors test changes without having to do bootstrap
at all.
It also makes it easy to test against multiple flavors without having to
swap out installed packages. You can even run tests against multiple
flavors simultaneously without interfering, if you have enough RAM.