TYPO3 Core

blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/

This patch changes travis-ci configuration to use the
new docker based containers.

Using them has the advantage that cache option can be enabled
which speeds up composer install. Additionally a bit more CPU
power is available.

OTOH mysql no longer runs in a ramdisk, so the db and table
creation is much slower. Also sudo is missing, so an own
ramdisk can not be mounted. Additionally, parallel can not
be installed via apt-get anymore.

The patch jumps through quite some loops to enable this nevertheless:

• Gnu parallel is compiled on its own
• An existing ramdisk in /dev/shm is used to start an own mysql there
• The ramdisk is limited in size to 64MB, so only 5 functionals are
  started in parallel and they clean up the database after finish.
  An own my.cnf configures mysql to route the 20MB ibdata1 file to /tmp
  so it does not eat up our required space. innodb_file_per_table makes
  the single databases store its stuff in own files.

All in all, this setup does not speed up the build: Functionals are
still significantly slower and also the php lint test takes at least
double time - while the composer cache does work and usually saves us
around 20 seconds and also the unit tests are about 10 to 20 seconds
quicker.

I'd guess, the current VM's give more CPU's to the clients than there
is in hardware. Travis-ci says they guarantee 1,5 CPU's But they are
overcommitting hardware. Our current test set up uses this and eats
as much as it can. Thats probably also the reason why our build slows
down significantly if travis is fully loaded.

The amazon EC2 based docker instance instead guarantees 2 CPU's, and
also limits this to this amount. So we're limited to this and as a
result our builds are slower in the end.