`composer self-update` has been failing regularly on travis recently.
As `composer` is already installed and it's not strictly essential to have the very latest version, this change allows the build to continue, even if composer can't self-update
Creates a package definition from the framework version being built,
and uses composer to install it into an installer project, as well
as the required modules for testing.
We'll need to fix the "no space left on device" issue,
most likely caused by Postgres keeping too much of a query log,
or somehow creating a history of past data.
For now, having a Postgres build breaking the whole
build process (incl. MySQL builds) does more harm than good.
Although PGSQL build will still be executed, a failure of that build won't registre as a Travis failure. This is a workaround until the PGSQL build has been fixed.
At this stage, the test just checks line-length and line-endings, but previous commits have ensured that framework actually passes those tests. We can add more tests as we actually correct the code to pass those tests, and grow the test suite, as we had for unit tests.
We don't currently use SQLite for any production deploys, and testing every build against it is overkill.
I'm removing this to be a bit nicer to the Travis servers; if we start relying more on SQLite's performance
in the future we can always revert this commit.
The Travis config will now run tests on the following instances
* 5.3 + SQLite
* 5.3 + MySQL
* 5.3 + PostgreSQL
* 5.4 + MySQL
In other words, with the exception of Windows tech (MSSQL + Win server) this is a wide-coverage build config.
