unsetbit / queen Goto Github PK

I'm getting this with built-from-source Node 0.8.19.

[...snip...]
npm http GET https://registry.npmjs.org/zeparser/0.0.5
npm http GET https://registry.npmjs.org/tinycolor
npm http GET https://registry.npmjs.org/commander
npm http GET https://registry.npmjs.org/options
npm http 304 https://registry.npmjs.org/zeparser/0.0.5
npm http GET https://registry.npmjs.org/zeparser/-/zeparser-0.0.5.tgz
npm http 304 https://registry.npmjs.org/tinycolor
npm http 304 https://registry.npmjs.org/commander
npm http 304 https://registry.npmjs.org/options

> [email protected] install /usr/lib/node_modules/queen/node_modules/socket.io/node_modules/socket.io-client/node_modules/ws
> (node-gyp rebuild 2> builderror.log) || (exit 0)


npm ERR! TypeError: options.uid should be a number
npm ERR!     at ChildProcess.spawn (child_process.js:782:24)
npm ERR!     at Object.exports.spawn (child_process.js:618:9)
npm ERR!     at spawn (/usr/lib/node_modules/npm/lib/utils/exec.js:103:22)
npm ERR!     at exec (/usr/lib/node_modules/npm/lib/utils/exec.js:40:12)
npm ERR!     at /usr/lib/node_modules/npm/lib/utils/lifecycle.js:146:5
npm ERR!     at process.startup.processNextTick.process._tickCallback (node.js:244:9)
npm ERR! You may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <[email protected]>
npm ERR! 
npm ERR! System Darwin 12.2.0
npm ERR! command "node" "/usr/bin/npm" "install" "-g" "queen"
npm ERR! cwd /Library/WebServer/Documents/node
npm ERR! node -v v0.8.19
npm ERR! npm -v 1.1.9
npm ERR! message options.uid should be a number
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /Library/WebServer/Documents/node/npm-debug.log
npm not ok

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.

with node 0.10 i have this error during testing

[Queen Remote Server] Connection error by 127.0.0.1:53638: Error: read ECONNRESET

In the following code, I'm trying to listen for a worker provider's available event, but it never seems to fire.

var options = {
            captureHost : "localhost:9000",
            debug: function( str ) {
                console.log("debug..." + str )
            },
            log: function(str) {
                console.log("log..." + str )
            }
        };

        options.callback = function(instance) {
            open(instance.captureUrl);

            grunt.log.write(
                util.format("queen is now running on: %s", instance.captureUrl)
            );

            instance.on("workerProvider", function( provider ) {

                provider.on("available", function() {
                    grunt.log.write( "available\n" );
                    done( true );
                });

                console.log(provider);
            });
        };

        queen(options);

Am I missing something?

Thanks!

via the examples, tests will run in all connected browsers
but sometimes, i just want to run test in specified browsers
is there some way to do this?

Trying to find my way around to put a build environment together. Currently I'm trying to setup Queen/Thrill/SauceLabs to execute unit tests during a build from Jenkins.

Maybe I just misunderstood something but for me the Queen Sauce populator tries to keep the Sauce Labs browser pool current by re-spawning Sauce Lab VM's. At least for me I see new Jobs created in the Sauce Labs overview every 90 s. Each VM will timeout after 90s by default and a new one will be spawned by the Queen populator even if the first VM executed the tests successfully.

How does this fit into the time based payment of Sauce Labs?

I'd like to start Queen with the Sauce Labs configuration during build time and trigger the tests by executing thrill during build time. My issue here is that I can start Queen and thrill from the build process, but as long as no worker browser is spawned thrill will return immediately without running any test.

Am I missing something here or do I have to keep Queen running all the time, connected to Sauce Labs and consuming the test time? Or is there a way to synchronize the thrill to Queen connection to be executed only when the first worker from Sauce Labs is online after Queen was started?

Queen] Starting...
[Queen] Capturing browsers at http://localhost:9300/
[Queen] Initializing plugin: monitor
[Queen] Initializing plugin: populator
[Queen] Loading remote script: http://queenjs.com/server-example.js
[Queen] Executing remote script: http://queenjs.com/server-example.js

(i wait a few seconds without connecting any workers)

buffer.js:242
this.parent = new SlowBuffer(this.length);
^
RangeError: Maximum call stack size exceeded

OSX v10.7.5

josue@~/Sites $ sudo npm install -g queen
npm http GET https://registry.npmjs.org/queen
...............
npm http 304 https://registry.npmjs.org/commander

[email protected] install /usr/local/share/npm/lib/node_modules/queen/node_modules/socket.io/node_modules/socket.io-client/node_modules/ws
(node-gyp rebuild 2> builderror.log) || (exit 0)

CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
SOLINK_MODULE(target) Release/bufferutil.node
SOLINK_MODULE(target) Release/bufferutil.node: Finished
CXX(target) Release/obj.target/validation/src/validation.o
SOLINK_MODULE(target) Release/validation.node
SOLINK_MODULE(target) Release/validation.node: Finished
/usr/local/share/npm/bin/queen -> /usr/local/share/npm/lib/node_modules/queen/bin/queen
[email protected] /usr/local/share/npm/lib/node_modules/queen
├── [email protected]
├── [email protected]
├── [email protected] ([email protected])
├── [email protected] ([email protected], [email protected], [email protected])
├── [email protected]
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
└── [email protected] ([email protected], [email protected], [email protected], [email protected])

josue@~/Sites $ queen
-bash: queen: command not found

Currently Queen expects all autopopulators to maintain an active browser pool. This can be wasteful when Queen is using paid services (Sauce Labs or Browser Stack) and idling for long periods of time.

For example, if Queen is using browsers from Sauce, by default Sauce will shut down the browsers after 90 seconds (default timeout), Queen will interpret this as an error and ask for another browser to be spawned.

The solution may be to have an options for Queen lazy-spawn these browsers, so that the browser pool provided by autopopulators are only filled up if there are active jobs or pending jobs. This would add significant overhead to job start up time (as spawning the browsers take time), but it would prevent Queen from wasting paid browser time while idling.

As far as I can tell, queen never falls into the code path for actually initializing the remote worked, both in the stable branch and in master. Is this feature working currently? I see the plugins initialized, but I never see the code for a specific provide called (browserstack, in my case).

Currently, if Queen is started with autopopulators, followed immediately by a single-run job, the job will fail because no browsers are connected. Queen should queue up requests that occur during start up to run once it's ready to process them (when all browsers are connected).