unsetbit
commented
11 years ago 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
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.