SCSS linting now uses the node-based sass-lint tool, since we’re
shifting away from CodeClimate.
This has the benefit of not requiring a ruby gem on dev tools -
everything is provided as npm dev dependencies.
This was also necessary to run the linting inside travis.
The ‘npm run lint’ command will be used to run listing on Travis, which
can also be used on local dev environments. These can also be used with
editor plugins to highlight errors immediately.
The intention is that this can be used in place of codeclimate. The
benefits are that we use a single toolchain in both CI and local dev,
which is not entirely the case at the moment.
Note the sass-lint is provided by “sudo gem install scss_lint”. It’s
possible that we can move to a node-based sass-lint; I can’t recall
what the motivation for using the scss_lint gem was - I think it was
mainly that we had the AirBNB styleguide already implemented as a linter
config.
This shifts the behat test run to be triggered form composer activity
within the framework module directly,
* silverstripe/serve is used to provide a webserver, based on the
php -S command
* se/selenium-server-standalone is used to install selenium rather than
a download command
Because we’re using serve, the behat configuration can be locked down.
Further refinements could be made on this:
* the behat-extension could be responsible for installing and
starting/stopping selenium, making these tests more portable
* xvfb initialisation could be provided with another bin tool in the
begat-extension: vendor/bin/xvfb 1024x768
* The bootstrap-file argument to serve could be provided as part of a
composer.json setting. This would make it easier for developers to
start a dev server simply by running vendor/bin/serve
* the behat-extension could be responsible for installing and
starting/stopping silverstripe/serve, removing the need for
specifying base_url at all, and possibly utilising the same bootstrap
file between serve and behat.
The SilverStripe project structure complicates the travis test run, and
the goal of this branch is to prevent it from being necessary.
- Unit tests can be run simply with PHPUnit.
- Behat test can be run with the silverstripe/serve module
Note that initially this commit doesn’t cater to the behat tests.
As part of this, we allow dev packages to be installed when testing
These settings don’t affect projects that use framework, only when
framework’s composer install / require calls are used themselves.
Since SS4 is pre-stable, these are important. They can probably be
removed once SS4 stable (and stable versions of support packages) have
been released.
We've had a few failures where framework caused regressions in CMS,
so these builds are helpful. They'll increase the overall build
times on the "silverstripe" user because of Travis' build limitations.
The parallel per-build run times shouldn't increase, since
framework builds take longer than cms builds anyway:
CMS Behat build took 13:53 on last 3.3 run,
framework MySQL PDO build took 16:12.
- Includes a package.json file with build and CI scripts
- Includes shrinkwrap file for locking dependency version
- Includes Gulp for running build tasks
- Includes a 'build' task for copying library files from node_modules to thirdparty
- Includes a 'sanity' task for makes sure library files in thirdparty match what's in node_modules
- Includes updates to .travis.yml (new JS_SANITY_CHECK flag) to run the sanity task
It's important to test different databases. It's important to test
different versions of PHP. But we don't need to test all possible
versions of each tested in a cartesian product.
This patch ensures that there are 4 builds that cover:
- PHP 5.4, 5.5, 5.6
- MySQL, PostgreSQL and SQLite
- PDO and each db-specific connector
- Behat and non
Our build time is an impediment: frequently we're slowed down waiting for
test runs to complete. In this context, running allowed-failure builds
that everyone ignores is just a waste.
I'd love to see HHVM work, but that's going to require that someone
actually gets the build to pass. At that point, we can add it back into
the build matrix.
I'm working on a PHP7 branch that will hopefully also fix our nightly
builds. Once I get that going, I'll add those two back, but not have
'allow failures'
Even if we decide, at some point in the future, that supporting nightly
doesn't make sense, I see the *only* value of Travis is maintaining our
green tick. We either care about builds or we don't: I've never seen a
'grey area' build result in anything other than embarrassment and
technical debt.
Let's decide what matters to us and treat it like it matters to us:
it's part of the build or not.
`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
Travis support for PDO
ATTR_EMULATE_PREPARES = false breaks some test cases
Enable username sans password
Remove unnecessary semicolons delimiting queries
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.
