…VIS_PULL_REQUEST env var to either export false (if not a PR) or the PR number from GitHub
## Background Historically, projects that need various services (PostgreSQL, MySQL, RabbitMQ, etc) running either relied on the fact that CI env had them started on boot or `before_install` steps (or similar). This is about to change. ## The Change As the number of services grows and more and more large-ish projects join Travis, it becomes more and more obvious that we cannot have all those services started on boot and have enough RAM for large test suites. So we have a few options: * Add more RAM to each VM * Tune services to use less RAM * Disable some services from being started on boot We have been doing #2 and #3 for some time now but did not touch services that have always been started on boot (e.g. MongoDB or RabbitMQ). #1 will also happen thanks to our next gen (BlueBox) VM infrastructure. However, with BB we also move to 64 bit VMs and that largely eliminates some of the gains. The only realistic scenario seems to be disabling more services on boot, leaving only MySQL and PostgreSQL running by default. When we do that, projects will have to tweak .travis.yml to enable those services. Using `sudo service ... start` is straightforward but has some downsides * You need to know exact service names. Apparently some developers do not know them and some services have irregular names. * This makes hundreds if not thousands of .travis.yml files out there contain even more Linux/Debianoids-specific code. In the end Josh and I settled on providing a way to list services in .travis.yml in a way that will let travis-build handle irregular service names and (at some future point) OS differences. ## How It Works ``` yaml services: - riak # will start a service named riak - rabbimq # will start a service named rabbitmq-server - memcache # will start a service named memcached ``` That's about it.
pull_request_number should be in Commit, but there was no integration tests that would catch this error. This commit fixes the situation and contains tests that ensure that pull requests work as expected.
Those vars are set based on payload from travis, to allow easier scripting when using secure env variables or running pull request specific code.
Gonna extract this in a mixin soon.
mvn install output is so verbose it goes above the log length limit almost all the time even with relatively small Java projects. mvn install -q is too silent to my taste but there is no middle ground or I haven't found it yet. So lets deploy this and keep looking.
This reverts commit 9b15ea3. We cannot do this for git clone because we *then* do git checkout to a specific commit and submodules are left unupdated. So this has to be added as a separate git submodule update --init command that happens after git checkout.