search

deftjs / DeftJS

Extensions for Large-Scale Sencha Touch and Ext JS Applications
http://deftjs.org/
MIT License
285 stars 56 forks source link

Consider implementing continuous integration, adding build badge #80

Closed johnyanarella closed 11 years ago

johnyanarella commented 11 years ago

See: https://travis-ci.org/ and https://ci.testling.com/

Leaning towards Testling CI - the cross browser testing and status matrix would be valuable to Deft JS users.

johnyanarella commented 11 years ago

Added configuration files for running the Deft JS test suite via Karma Test Runner.

Travis-CI looks like the ideal choice for our needs.

Considering adding a Grunt script or new Ant target to execute all of the Karma configuration files (aggregating the result of the tests running for all of those configurations), or at the very least the configurations for the latest version of Sencha Touch and Ext JS.

I'd love to integrate Grunt, but I worry about adding yet another build dependency, especially since Grunt is still young (0.4). That said, grunt-karma looks great for our needs here.

superstructor commented 11 years ago

Re Grunt #85 would mean that the overall build would be executed via sencha package build, which is basically just Ant build scripts and plugins. It it works as an Ant target it will work with Sencha Cmd.

Of course we could shell out to anything, including grunt, for running tests if it integrates well at that level.

Keeping as much as possible with Ant targets may have the benefit of consolidating build configuration under .sencha/package/build.properties etc, rather than split across that and grunt.

Thoughts ?

superstructor commented 11 years ago

Alternatively we could switch it around and use Grunt to control the overall build process, then have a grunt task to shell out to Sencha Cmd for the essential Sencha tasks.

Under this scenario examples of grunt's responsibilities:

Examples of Sencha Cmds responsibilities (as a grunt task):

However there are some serious problems with this approach so I still think using Sencha Cmd to control the overall build is best.

With Grunt controlling the build this would require switching back and forth between grunt and sencha package build, which I don't think is possible ? E.g.

  1. CoffeeScript ( Grunt )
  2. Class-based dependency resolution ( Sencha Cmd )
  3. file concatenation ( Sencha Cmd )
  4. minification ( Sencha Cmd )
  5. karma test runner ( Grunt )
  6. documentation w/ JSDuck ( Grunt )
  7. generate distributable package (.zip) for Sencha Cmd repository ( Sencha Cmd )

With Sencha Cmd controlling the build if everything is a individual Ant target you can hook into the extension points at different stages of sencha package build. See Extension Points part of the Advanced Sencha Cmd Guide. E.g.

  1. CoffeeScript ( -before-build / Sencha Cmd )
  2. Class-based dependency resolution ( -before-js builtin / Sencha Cmd )
  3. file concatenation ( between -before-js and -after-js builtin / Sencha Cmd )
  4. minification ( between -before-js and -after-js builtin / Sencha Cmd )
  5. karma test runner ( -after-js / Sencha Cmd )
  6. documentation w/ JSDuck ( -before-pkg / Sencha Cmd )
  7. generate distributable package (.zip) for Sencha Cmd repository ( between -before-pkg and -after-pkg builtin / Sencha Cmd )

The problem is sencha package build is one shell command, thus one grunt task that must all run at once. Whereas Ant targets can be run at any point during sencha package build through the use of extension points internal to the package build process.

brian428 commented 11 years ago

Given the issues people tend to have running things through Cmd, using it for CI would also be a nice reference for others who want to use it to build their Deft JS apps.

I had looked at the Cmd extension points at one point (a while back) but at the time there was very little documentation on it. Now that we have more info, this seems like a good idea for CI. With the bonus that others could probably clone our approach to use in their own apps.

brian428 commented 11 years ago

Which reminds me: John, did you ever think further on how to handle the problem that we currently need to set up a separate loader file to ensure the 3 necessary Sencha JS classes are loaded before Deft starts up? I swear there was some reason we were hesitant to add it to the top of the Deft JS lib file, but right now I can't remember what the reason was.

May be off topic here though....Cmd should embed all the relevant Sencha classes before it embeds Deft, so I don't think this is an issue for CI via Cmd...

johnyanarella commented 11 years ago

The test directory now includes a new ant script with a test target that will execute the Deft JS unit tests using Karma Test Runner for all supported versions of Sencha Touch and Ext JS. The browsers used are configurable via the karma.browsers property, via build.properties or the command line (ex. -Dkarma.browsers=Chrome).

The main build.xml includes a test target that calls this new ant script as a subtask.

johnyanarella commented 11 years ago

Excellent news!

Integration with Travis CI worked on the first try. Our first Travis CI build passed - executing the current suite of 984 unit tests on four versions of Sencha Touch and four versions of Ext JS.

I'll integrate the build badge into the README.md when I get a chance.