Like godep, govendor helps manage the native Go vendor dir. But it also
supports a mode where you don't have to copy all the files into your own
repo. Instead, you run `govendor sync` after updating the `vendor.json`
file, and it reconciles everything by downloading as needed.
This gets rid of the warning about disabling native vendor mode
due to legacy Godeps/_workspace directory being present.
It also means we require Go 1.5+ since that's when native vendor
mode was first introduced.
Add `--docker` flag to run preview/publish without needing to set up
Ruby or Jekyll:
``` sh
vitess$ ./preview-site.sh --docker
vitess$ ./publish-site.sh --docker
```
The ENV version was not working anyway since Docker did single-quote: '-j$(nproc)'
Because of that make saw this string literal and converted it into an (unknown) absurd high number. On my 12 core machine it executed way more jobs in parallel than 12. This change will also fix this.
This gets rid of the opaque mysql-db-dir.tbz archive, replacing it with
a .sql file. The .sql file approach makes it clear what state the DB is
initialized with, and also makes it easy to customize.
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".
The base images are meant for development, and include everything needed
to bootstrap and build Vitess.
For actual deployment, we can drop all the dev packages and just put the
binaries into a fresh image.
At this time, the savings in image size are:
vitess/base = 2.269GB -> vitess/lite = 568.4MB
vitess/etcd:v0.4.6 = 442.4MB -> vitess/etcd:v0.4.6-lite = 108.6MB
This makes Kubernetes pods start a lot faster, since each node has to
download the images.
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.
This makes it faster to use Docker images to test new changes, as
suggested in #492.
Since we don't need to re-bootstrap for every push to master, this also
makes our automated builds faster and more reliable (they often fail due
to network lag when installing dependencies with apt-get).
Lastly, this will make it easier to swap out bootstrap images built for
different flavors, such as MariaDB 10.0 vs MySQL 5.6.
Alain Jobart
Anthony Yeh
Michael Berlin
Rasta
Ammar Aijazi