Grunt task for running local queen server

[plumlee]

Wondering about the feasibility of a grunt task for spinning up/down a queen server. We do both local dev testing and CI testing via grunt, so this would be a nice compliment to the grunt-thrill task. Is this something you've already got in the works?

Although I could use grunt-shell for some of this, it would be nice to have a full start/browser spin-up/test via thrill/kill browsers/stop server process. It also looks like using grunt-util would work for spawning a child process and perhaps returning that for later access to be able to stop it.

As a full solution, passing an option to run a particular grunt thrill task would also be useful. So for CI, run the full browser suite of tests. For local development, maybe run a smaller thrill task.

Just curious about your thoughts here.

[unsetbit]

Queen is intended to be a resource pool which can be utilized by the likes of Thrill. So while grunt-thrill exists, and we use it at Turn, there hasn't been a need for a Queen task for us. If you'd like to launch browsers at build-time, Karma (https://github.com/karma-runner/karma) is a much better candidate. Queen optimizes for reducing the most time intensive task, launching browsers, by having a persistent pool ready to work and accept remote connections (so each dev doesn't have to launch their own instance). Therefore, while it makes sense to have the lifecycle of Thrill be within a build transaction, Queen is intended to be an ever-present resource which can be tapped into.

It seems that you're using Queen with Browserstack, which is currently a bit problematic because Queen expects the browsers to be always active, so it can waste paid minutes for services like Browser Stack and Sauce Labs while the browsers sit idle. Ideally, Queen would be able to initialize remote browsers from these providers only when they're being utilized, but that's a feature for the next release.

If you'd still like a grunt task, it should be pretty simple to do. Both thrill and queen have a concept of "runner" as an initialization mechanism. In Thrill, https://github.com/turn/thrill/blob/stable/bin/thrill sets up a config object to pass to https://github.com/turn/thrill/blob/stable/lib/server/runner.js. Grunt-thrill, https://github.com/oztu/grunt-thrill/blob/master/tasks/thrill.js, is only a 20 line file which sets up the config object in a different way to pass to the same runner. In the same way, you can look at how https://github.com/turn/queen/blob/stable/bin/queen just sets up a config object to pass to https://github.com/turn/queen-remote/blob/stable/lib/runner.js and write a similar grunt task.

[plumlee]

Thanks for the feedback, and hope I'm not taking too much time away from your vacation. Karma looks pretty sweet, so I'll probably add that as an option as well in the overall workflow. I have a need for both situations - allow a dev to fire up local browsers for testing, and spin up remote browsers if needed. I will look at a grunt task following the path you suggested - I had started looking at the runner to see how things worked already.

[plumlee]

Getting close on a grunt task,but seems like the queenConfig file is read, but the populator option is ignored. Perhaps I'm not following how the queen-remote works - can I pass it the options to autopopulate?

[unsetbit]

I know this is a bit late, but I'm doing some issue cleaning.

The config is passed like so queen -> queen-remote -> queen-plugin-populator. The populators from the config are read here: https://github.com/oztu/queen-populator-plugin/blob/stable/lib/manager.js#L14 and the autopopulation routine is called automatically (https://github.com/oztu/queen-populator-plugin/blob/stable/lib/manager.js#L41).

[plumlee]

Thanks for the update. I haven’t been able to get back to this since then, so if you’d like to close this, that’s fine. Or leave it open for anyone else to pick up as they want.