-
Notifications
You must be signed in to change notification settings - Fork 96
Open
Description
I dug into the details here, and basically here's what's going on:
The default number of fetch attempts to get the status is effectively infinity
. Now, when there's a browser config issue, the test is never started, and the result that it gets back is not handled correctly:
$ grunt test:broken
Adding environment variables
Running "test:broken" (test) task
Running "connect:server" (connect) task
Started connect web server on http://0.0.0.0:9000
Running "saucelabs-mocha:broken" (saucelabs-mocha) task
=> Starting Tunnel to Sauce Labs
>> Connected to Saucelabs
1 / 1 tests started
Result of test: { status: 'test queued',
platform: [ 'OSX 10.6', 'safari', '5.1' ],
id: '4c73b921ab4c40aeab7d8fb19e422d20',
job_id: 'job not ready' }
Result of test: { status: 'test error',
platform: [ 'OSX 10.6', 'safari', '5.1' ],
id: '4c73b921ab4c40aeab7d8fb19e422d20',
job_id: 'job not ready' }
Even though the status is 'test error', status
is never read. It relies purely on job_id
and continues running until it gets back an alphanumeric value.
The fix here is pretty simple. result.status just needs to be checked to see if it is 'test error'
src/Job.js:156
if (result.status !== 'test error' && (!body.completed || !reJobId.test(jobId))) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^
A little more might need to be done to get the reporting to line up though, but that at least allows it to pass.
Metadata
Metadata
Assignees
Labels
No labels