Added support for 'start' in background and 'run' goals

[nidi3]

In our build infrastructure, we cannot start a browser from within the build process.

So I added the possibility

• to start a karma server in the background (goal 'startServer'). The server keeps running so that browsers can be connected to it whenever needed.
• and then use this server to run the tests on all connected browsers (goal 'run').

What do you think?

[kelveden]

Thanks for the request - I don't have time to look at it right this moment but I'll endeavour to do so over the weekend. Sounds good in principle though - I considered doing something similar when I first setup the plugin but I wasn't sure there was much a of a need for it. Sounds like I was wrong :-)

[kelveden]

Hi @nidi3. Thanks again for the pull request. I've just had a spare few minutes to look through it. As the idea of the plugin is simply to pass through directly to the karma executable, a separate "run" goal hooking directly up to the "run" task from karma makes sense. So, that part looks good to me (as does separating the shared functionality into the abstract mojo of course).

What I'm a bit puzzled about is the necessity for the "startServer" goal. Isn't that functionality already present in the "start" goal of the plugin by setting the "singleRun" property to false? I'm also a bit nervous about that "killall" functionality in there - the plugin could be killing processes that it didn't create and thus could have unwanted side-effects.

Thoughts?

(By the way, I'm going to be in a lot of flux for the next few weeks for a plethora of reasons - so bear with me if I'm slow in replying!)

[nidi3]

Hi @kelveden. Thanks for replying.

The difference between 'start' and 'startServer' is that the later runs karma in a background process that will be running even after the build has finished. See the difference in createKarmaProcess method. This allows you to connect browsers to it manually at any time.

On the other hand, it makes it necessary to stop the already running karma instance on every build. That's why the 'killall' is used. You are right that it might kill unintended processes.

I created an issue https://github.com/karma-runner/karma/issues/136 to add the feature to stop karma. This would be a much cleaner solution.

So maybe we should wait until karma has implemented a stop function.

[kelveden]

Yes, that would certainly be my preference. I'll keep this pull request open for the moment until there's a resolution.

[kelveden]

Judging by the connected karma-runner issue nothing is going to happen on this so am closing for now. Re-open if something happens on the karma issue.