Version 0.2.4.1 - Bugfix dynamic port allocation

Whats new

Dynamic port allocation

If you set port to 0 in buster config. The plugin should find a free port for you automatically. Implementation was flawed. Improved (but not perfect), and seems to work ok for local tests.

Version 0.2.4 - Improved autotest handling

Whats new

Throttling file change events

Depending on OS, the autotest feature was a bit eager on starting testruns in buster. This could lead to several consecutive runs even though you might have just made changes to one file.
Autotest now throttles file change events and starts a testrun after a given quiet period.

Picks up changes in buster.js

At the cost of slightly more latency for starting testruns, changes in busterconfig will be picked up on any file change.

Dependencies clean up

Sigar was used in previous versions for process managment. Currently it is only used for testing purposes, so changed dependencies to be test scoped.

Version 0.2.3 - Improved logging and busterAutoTest output

Whats new

Improved logging

Taking more control over the log-output from the PhantomJSDriver. It't didn't really adhere to the slf4j loglevels, so the plugin now propagates the gradle project loglevel to phantom js ghostdriver. Net result is less verbose console log by default.

Better report ouput from busterAutoTest

Changed the buster test reporter used for the busterAutoTest task. Its very compact, but informative enough.

XML issues

Some issues with buster testing have been reported that indicates that either the plugin or buster mangles the junit xml output from the busterTest task. Added logging of xml when failure to parse. Please report (with xml) if you experience this problem.

Version 0.2.2 - Concurrent CI builds and Incremental support

Whats new

Concurrent CI Builds

Previous version of the plugin relied on pids and killing the buster-server process by name. This could become troublesome in CI environment where chances of two or more builds running buster tests concurrently are greater.

This version now keeps hold of a java.lang.Process object representing the spawned buster-server process. Hopefully this should work ok on most platforms.

Incremental support

The busterTest task now has incremental support. Buster testing is fast, but capturing browsers and releasing browsers does take some time. In larger multiprojects incremental support is obviously even more valuable.
The inputs of the busterTest task is basically the buster.js (or whatever you may have named it) configuration file and any files matching patterns defined within the configuration file.

The plugin does a best effort attempt to parse the buster configuration file, but the buster-configuration options are very flexible so the parsing isn't watertight... A issue request to buster for an API to query about resolved files have been raised with the buster project.

Version 0.2.1 - Support for buster 0.7.5+

Whats new

Support for buster 0.7.5+

The buster 0.7.X beta releases promises to be much more stable. A few things were deprecated so that the plugin needed to adapt to. Should still work with older versions of buster.

Specify path to buster executables

You may now specify the path to the buster executables either through a configuration setting or as a system property. Handy when you wish to have control over which version of buster you are running etc.

Version 0.2.0 - Testing with multiple browsers

Whats new

Testing with multiple browsers

• You can now run busterTest with multiple browsers using the plugin
• PhantomJS is default used and expected unless you specify additional browsers
• You can easily separate which browser(s) you wish to test with in CI and which you test with in local dev (using gradle init scripts)

Better process handling

The buster server process is a spawned process. The previous version was not always reliable in terms of killing this process after completion. Sigar has been introduced to better handle process management cross-platform (kudos to stigkj for contributions). In addition buster server is always killed after busterTest is run.

Breaking changes

• The following tasks have been removed from 0.1.1: capturePhantom, startBusterServer, stopBusterServer and stopPhantom.
• This means you may no longer just start the server and later do busterTest. The task busterTest will always start a buster server and capture browsers before running tests. It will also always shutdown browsers and stop the buster server when the tests have completed (regardless of test failure or not)