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
