bermi / sauce-connect-launcher Goto Github PK

Please add licensing information.

Currently if someone CTRL+C's the launcher while the Sauce Connect zip is downloading, you will be unable to start the tunnel (unless you manually rm the partial zip). All subsequent invocations of launchSauceConnect will poll every second ad infinitum until the jar file exists, because they assume another process is downloading it.

Either we should take away this assumption, have some way to determine that another process is downloading, or capture SIGINT and have it remove the zip.

Hey, trying to use this on Windows 7 and seems like setting permissions on the downloaded Sauce Launcher is causing an error.
I tried this inside a VM in a VMWare shared folder and then tried just on a local C:\ drive .

Possible Fix: Remove the setExecutePermissions call on Windows. In my testing that helped and Sauce Launcher worked perfectly.

I've had many troubles the last weeks getting around SSL popups that blocked my tests from executing. They occured before my actual tests were initialized, by the default google.com domain that was opened in the browser:

After many emails SauceLabs replied:

Hi Julian,

Apologizes for the delayed response as were in a company off-site and support assistance was limited in between meetings. All of our Android VMs are booted with the Android stock browser launching the defaulted Google home page before your test is implemented.

What’s happening is that Sauce Connect does a re-encryption in which it takes the original certificate of the site that you are trying to access and re-encrypts it with the Sauce Lab’s CyberVillains certificate. We noticed that for Android 4.4 the stock browser in the emulator classifies the CyberVillains certificate as a not trusted authority and that is why it shows this Security Warning prompt.

Since you mentioned this test has worked previously on the Android 4.4 emulator in the past, can you provide the Sauce job URL so I can take a closer look into it? Thanks for your patience and understanding.

Regards,
Albert

and

Hi Julian,

Thanks for the Sauce job URL. We have recently ended support for Selendroid earlier this month, which was used with Karma tests in the past with Android 4.4 web tests (https://wiki.saucelabs.com/pages/viewpage.action?pageId=67012495). With Selendroid a different underlying browser was used, which was not affected by the certificate pop-up you encountered.

As you can see in your passing Sauce job URL, the following lines appear in the selenium-server.log:
Jan 04, 2017 9:31:12 AM io.selendroid.SelendroidLauncher launchServer
INFO: Starting selendroid-server port 4443

Now all Android 4.4 web tests will use Appium by default moving forth. If you look at the appium-server.log in the Sauce failing tests, you will the following lines:
2017-01-06 20:44:27:072 – info: Welcome to Appium v1.4.16 (REV ae6877eff263066b26328d457bd285c0cc62430d)
2017-01-06 20:44:27:074 – info: Appium REST http interface listener started on 0.0.0.0:4443

Using the (-B all) or (—no-ssl-bump-domains all) flag with Sauce Connect will be required when testing against Android 4.4. Thanks for your patience and understanding.

Regards,
Albert

As no one with Karma can now execute tests on Android 4.4 without adding --no-ssl-bump-domains or -B (which doesn't seem to work btw, see karma-runner/karma-sauce-launcher#110) I think this should be explicitly documented (at least the option).

It looks like the current project maintainers no longer have time / interest to maintain this module (unanswered issues / PRs, no CI).

If this is the case, would you be open to add further maintainers to this repository? I have some tools depending on it,
https://github.com/johanneswuerbach/saucie https://github.com/johanneswuerbach/ember-cli-sauce, but they need further features which kind of belong into this repository (checksums, retries). I'm definitely willing to contribute the code, but wanted to check whether this project is alive before starting the work.

Ping @bermi, @jlipps, @Jonahss

When trying to close a tunnel, the tunnel actually won't get closed and the Sauce Connect process will just be killed, because child.tunnelID is undefined here. Looks like Sauce Connect changed the format of reporting tunned ID, e,g. for Sauce [email protected]:

20170329 181648.474 [12860] Started scproxy on port 52822.
20170329 181648.474 [12860] Please wait for 'you may start your tests' to start your tests.
20170329 181718.801 [12860] Provisioned tunnel:189120672ce64a249c1ed1ab6eac694c

IMHO the fix is changing RegExp here from /Tunnel ID:\s*([a-z0-9]+)/i to `/Provisioned tunnel:\s*([a-z0-9]+)/i

For users in restricted network environments, the automatic downloadAndRun functionality will fail to download sauce connect.
I understand the issues around using less-secure methods of downloading the proxy, but the current workarounds a bit of manual work: https://github.com/Polymer/wct-sauce/issues/5#issuecomment-164083574.

I'd like to propose a new option, scPath, that will run the sc file at the given path and reuse all the startup/teardown logic this module already provides. That way it is up to the user to provide the sc binary without sacrificing the security of procuring it from this module.

What do you think?

Current code:

req.on("response", function (res) {
    var len = parseInt(res.headers["content-length"], 10),
      prettyLen = (len / (1024 * 1024) + "").substr(0, 4);

    logger("Downloading " + prettyLen + "MB");

    res.pipe(fs.createWriteStream(archivefile));

    // cleanup if the process gets interrupted.
    process.on("exit", removeArchive);
    process.on("SIGHUP", removeArchive);
    process.on("SIGINT", removeArchive);
    process.on("SIGTERM", removeArchive);

    function done(err) {
      if (err) { return callback(new Error("Couldn't unpack archive: " + err.message)); }
      // write queued data before closing the stream
      logger("Removing " + getArchiveName());
      fs.unlinkSync(archivefile);
      logger("Sauce Connect installed correctly");
      callback(null);
    }

    res.on("end", function () {
      async.series([
        unpackArchive,
        setExecutePermissions
      ], done);
    });

  });

  req.end();

setExecutePermissions is only called if sc didn't exist earlier.
However, if you package the node_modules permissions on the file might be lost.
Which leads to this error:

I use the JWT addon of Travis CI to generate time limited access keys, so that I'm able to build PR's without making my real access token public.

Unfortunately the already existing encoding of user credentials does not work for JWT access keys.

Output:

Starting sc with args: -u XXXXXXXX -k eyJ1eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJUcmF2aXMgQ0ksIEdtYkgiLCJzbHVnIjoiemluc2VyamFuL3dkaW8tc2NyZWVuc2hvdCIsInB1bGwtcmVxdWAzdCI6MzgsImV4cCI6MTQ3NDM5NzcyOSwiaWF0IjoxNDc0MzkyMzI5fQ.1RUDpq1nYGLiJpLiEV9Vt8qGDqPCagkgVN6qEjs0dnY --tunnel-identifier 166.3 --verbose --readyfile /tmp/sc-launcher-readyfile

Expected:

Starting sc with args: -u XXXXXXXX -k XXXXXXXX --tunnel-identifier 166.3 --verbose --readyfile /tmp/sc-launcher-readyfile

I'm new to Node.js development in general so this may already be available and I'm just not understanding how to access it. I use TeamCity for CI and the TeamCity plugin requires that I create a message of the format SauceOnDemandSessionID= job-name=. While job name comes from my environment, session id comes from the webdriver. After doing some tracing, I notice that a variable named jobMessages will eventually get the session Id that I require but I don't know how to access it. So here's my question: Is there a way to havean option to get the launcher write these messages for users that require it (Both TeamCity and Bamboo have the same format, so it's not TeamCity specific)? Or is there something else I need to do in order to have access to this variable and write it out myself?

If there is an error with SauceLabs VMs, is it possible to catch that and throw exit status 1?

function getArchiveName() {
  return {
    darwin: "sc-4.0-latest-osx.zip",
    win32: "sc-4.0-latest-win32.zip"
  }[process.platform] || "sc-4.0-latest-linux.tar.gz";
}

function getScFolderName() {
  return {
    darwin: "sc-4.0-osx",
    win32: "sc-4.0-win32"
  }[process.platform] || "sc-4.0-linux";
}

You first download sc-4.0-latest-linux.tar.gz but then inside there is sc-4.1-linux, and you expect sc-4.0-linux. I guess if the folder name was auto detected it would have worked just fine.

From: https://docs.saucelabs.com/reference/sauce-connect/

-t, --tunnel-domains <...>      Inverse of '--direct-domains'.
                                Only requests for domains in this 
                                list will be sent through the 
                                tunnel.

Thank you.

Sometimes SauceConnect just hangs, non-responsive on either the connection or disconnection process. Would it be possible to set a timeout, and retry the connect/disconnect process if no response received?

Currently the detached option is only supported for sc <= 4.3.16 due to a bug in the golang reimplementation done in 4.4+
https://github.com/bermi/sauce-connect-launcher/blame/v1.1.1/README.md#L119

A support case has been opened, but no fix is available so far.

The install script wants to make use of lodash.

I suspect that because I have a direct dependency on lodash, npm is deciding to install lodash at the top level only, and is also not finished doing so by the time my application's npm process tries to install sauce-connect-launcher.

All of this is to say that I get:

> [email protected] install /Users/ssalsbur/Documents/_ws/marklogic-samplestack/browser/node_modules/sauce-connect-launcher
> node scripts/install.js

|
module.js:340
    throw err;
          ^
Error: Cannot find module 'lodash'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/ssalsbur/Documents/_ws/marklogic-samplestack/browser/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:6:7)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
npm ERR! [email protected] install: `node scripts/install.js`
npm ERR! Exit status 8

(and I think it's because of npm timing).

I believe this might be solved by changing the install step to a prepublish step as per https://www.npmjs.org/doc/misc/npm-scripts.html .

I was going to try to such a change and then submit a PR if it helped, but the next problem I ran into is that when I try to install sauce-connect-launcher from the git repo, I get an error that grunt-simple-mocha could not be found in the registry, so I abandoned the concept of testing whether or not that change would help.

Do you think it would help to switch from a a scripts: { install: "..." } script to a scripts: { prepublish: "..." } script?

I saw this after updating my reference to sauce-connect-launcher from 0.6.1 to 0.7.0. I'm going to try reverting to see if that helps.

UPDATE: yes, reverting to and hardcoding 0.6.1 fixes the install issue.

> [email protected] postinstall /myproj/node_modules/sauce-connect-launcher
> node scripts/install.js

-
/myproj/node_modules/lodash/dist/lodash.js:4410
    /**
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Unexpected token ILLEGAL
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/myproj/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:6:7)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
npm ERR! [email protected] postinstall: `node scripts/install.js`

This is getting ridiculous if it wasn't already ridiculous. It seems that maybe postinstall is just more likely to be late enough that lodash will be available, but it is still not guaranteed. In this case I'm guessing that the the file was only partially written by the time it was used, given the error message.

I see no recent activity on npm/npm#6624.

Ugly workaround: rerun npm install since, after the first attempt, lodash (on which my package directly depends) will have already been fully installed.

I almost hate to mention this, but Is it worth considering putting some sort of error handling in that will retry until require('lodash') succeeds?

The latest sauce connect had a fix that solves our connection issue to sauce. So I would like to know, when would be the latest [4.3.9 or 4.3.10] add to the launcher.

Thanks,
Raghul

Checked to see if the adding 'tunnelDomains' works within the sauceConnectLauncher options and it does.

Recommend updating readme to include this option.

var options = {
            username: username,
            accessKey: password,
            tunnelDomains : '*domain1.com,*domain2.net'
        };

        var promise = new Promise(function(resolve,reject){
            sauceConnectLauncher(options,function(error, sauceConnectProcess){
            if (sauceConnectProcess.tunnelId) {
                console.log('id = ' + sauceConnectProcess.tunnelId);
                resolve ();
            } else if (error){
                reject (error.message);                
            }
        });
        }).then(function(result){
            console.log('Tunnel Is Established');
        },function(error){
            console.log(error);
        });

        return promise;

Hi, it seems that you are missing the sc --dns option

Sauce is publishing Sauce Connect checksums. Those should be verified to prevent correct archives were downloaded.

Per the Sauce Connect docs:

 -f,--readyfile <FILE>                       Ready file that will be
                                             touched when tunnel is ready.

This is a more efficient and reliable way to figure out the tunnel is ready, rather than grepping Connect's stdout.
I may take a stab at this next week, but I thought I'd report in case anyone is interested in fixing it.

Given @aearly and I are not actively using Sauce Labs on our projects, it's becoming increasingly difficult to keep up with feature requests and bug requests.
These have been mostly related to changes and additions on the Sauce Connect jar, so we decided to get in touch with the team at Sauce Labs to check if they could also help out.

It looks like Sauce Labs is going to have some resources to help keeping this project in sync with sauce connect.

@sebv, @jlipps as discussed via email I'm happy to share ownership of this repo and the npm package with your team. Please send me the npm and github user names for the people that will be helping out.

Hi,

I just received an email from saucelabs that sauce-connect is vulnerable to the heartbleed bug.
All customers should update to v4.1 of sauce-connect and update passwords.

Here is the part of the message on sauce connect:

For our customers who use Sauce Connect to test their applications behind their firewall, we have no specific evidence that data has been compromised. We have now updated our Sauce Connect servers so they are no longer vulnerable to new attacks enabled by the Heartbleed bug.

During the period of time when the Sauce Connect servers were vulnerable, attackers may have gained access to customer test data (traversing the Sauce Connect tunnel). If that has occurred, attackers may have the ability to similarly compromise future Sauce Connect 4.0 and 3.0 sessions. Again, we have no specific evidence that this has actually occurred.

As part of closing this potential vulnerability we have updated our certificates for Sauce Connect in version 4.1, and released a version 3.1 with updated certificates for those customers who prefer to stay with the 3.x line for now.

Customers will need to:

Upgrade to Sauce Connect 4.1 or 3.1 as soon as possible:
Sauce Connect 4.1:
OS X: https://saucelabs.com/downloads/sc-4.1-osx.zip
Linux: https://saucelabs.com/downloads/sc-4.1-linux.tar.gz
Windows: https://saucelabs.com/downloads/sc-4.1-win32.zip
Sauce Connect 3.1 (cross-platform):
https://saucelabs.com/downloads/Sauce-Connect-3.1-r32.zip
Change all passwords that could potentially have been affected if an attacker did have access to test sites and commands

Hi Bermi,

I would like to use proxy pac support in sauce launcher. Is it currently available? If not, can you please add this feature. Sauce supports --pac in command line.

sc -u xxx -k xxx --pac xxx

Thanks,
Raghul

What is the syntax for this. I use Sauce connect launcher via a WDIO service and have added the username of the owner for the parent tunnel in my browser caps, but so far no luck. Does this package interfere with parent tunnel?

On our Jenkins environment, we would like to be able to run multiple sauce jobs in parallel on one VM.

We ran into issues because multiple jobs write to the same readyFile, causing one job to think the tunnel is ready when another job's tunnel is ready.

It would be great if there were a readyFile option in the launcher constructor to allow specifying a unique readyFile name (which we could then pass via some unique number such as build ID)

Thanks for the great plugin!

Please create a new release to bump the Sauce Connect version

adm-zip has an irresponsible "greater than" dependency on node-fidonet-mailer-binkp-crypt, which has a very unsettling list of irresponsible "greater than" dependencies and a tendency to not build in a cross-platform fashion.

This module cannot rely on adm-zip if it is going to be used in testing environments. adm-zip and its dependencies are far too brittle to be trusted.

This is maybe kind of a big deal. Your dependency on adm-zip is picking up badly versioned code downstream. Those authors have pushed changes that violate semver, and the result is Linux systems without proper build dependencies that run CI tests using this module are breaking.

See:
cthackers/adm-zip#121
askovpen/node-fidonet-mailer-binkp-crypt#8

As an improvement to this really handy project, I'd suggest moving off adm-zip and instead using the zlib support that's built into node?

http://nodejs.org/api/zlib.html

At the least don't blindly accept downstream updates from them? They have obviously unreliable dependencies.

Seems like that library is a lot smaller now, faster tests!

Ref http://sauceio.com/index.php/2014/02/meet-the-new-sauce-connect-4/
http://saucelabs.com/docs/connect

I store a reference to the sauce connect process in my build setup so I can close it when my tests are done, but recently I've been getting this error every time I run it:

/Users/philipwalton/Projects/xxx/xxx/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:564
    var tunnelId = child.tunnelId;
                        ^

TypeError: Cannot read property 'tunnelId' of null
    at ChildProcess.child.close (/Users/philipwalton/Projects/xxx/xxx/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:564:25)
    at process.on (/Users/philipwalton/Projects/xxx/xxx/gulpfile.js:203:42)
    at emitOne (events.js:101:20)
    at process.emit (events.js:188:7)
npm ERR! Test failed.  See above for more details.

Let me know if you need any more information from me.

Hi,

When using sauce-connect-launcher, running nightwatch -e chromemac,ie11 only one environment actually runs. You can see from the output below that an environment finishes straight away.

Have you seen this before?

Thanks,

Started child process for: chromemac environment 
Started child process for: ie11 environment 

  >> ie11 environment finished.  

In my nightwatch.conf.js I have set some before/after globals in order to start the launcher:

  settings.test_settings.default.globals = {
    TARGET_PATH: target,
    before: (done) => {
      Promise.resolve()
        .then(() => (!settings.selenium.start_process)
          ? openSauce()
          : Promise.resolve()
        )
        .then(done)
        .catch(catchError);
    },
    after: function (done) {
      Promise.resolve()
        .then(() => (!settings.selenium.start_process)
          ? closeSauce()
          : Promise.resolve()
        )
        .then(done)
        .then(() => process.exit(0))
        .catch(catchError);
    }
  };

and the open/close sauce functions are:

let sauce;
const closeSauce = () => new Promise((resolve, reject) => {
  sauce.close(resolve);
});

const openSauce = () => new Promise((resolve, reject) => {
  sauceConnectLauncher(sauceConfig, ((err, process) => {
    console.log("Started Sauce Connect Process");
    sauce = process;
    err && reject(err);
    !err && resolve(process);
  }))
});
const catchError = (e) => console.log(`e`, e);

Please add proxy support.

I think itll be usefull to use npms proxy setting as it should be set as default.

Following http://semver.org/#how-do-i-know-when-to-release-100 I would propose to bump the next version to 1.0 and allow package consumers to easier differentiate between breaking changes / new features or patches. Currently every 0.x release can contain breaking changes according to semver and package consumers can't just use ^0.x to get new features / sc versions.

Before cutting 1.0 the following should be done (from my point of view):

• Merge #101
• Merge #99
• Merge #97
• Remove support for Node 0.10 & 0.12 as both are already EOL or will soon be https://github.com/nodejs/LTS

WDYT? @bermi @jlipps @sebv @aearly @Jonahss

Downloading https://saucelabs.com/downloads/sc-4.3.5-osx.zip (2.92MB)
Unzipping /app_root/node_modules/web-component-tester/node_modules/sauce-connect-launcher/sc/sc-4.3.5-osx.zip

Invalid or unsupported zip format. No END header found

I am getting this error ~80% of the time when I run npm install on a project with sauce-connect-launcher in its dependencies. Occasionally, the download works, but it usually doesn't. when it doesn't, my whole npm install fails.

Is this just an issue with that zip file, or is there another factor? What needs to be done to make the install stable?

Seems SAUCE_CONNECT_VERSION isn't required (or is it a bug?). Here is the command I use to download and install sauce connect binary with npm install

 SAUCE_CONNECT_VERSION=4.4.1 SAUCE_CONNECT_DOWNLOAD_ON_INSTALL=true npm install

Error happens in the console log

> [email protected] postinstall /Users/lzhu9/Develop/crows-nest/node_modules/sauce-connect-launcher
> node scripts/install.js || nodejs scripts/install.js

Checksum check for manually overwritten sc versions isn't supported.
module.js:340
    throw err;
    ^

Error: Cannot find module '/Users/lzhu9/Develop/crows-nest/node_modules/sauce-connect-launcher/sc/versions.json'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:289:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at done (/Users/lzhu9/Develop/crows-nest/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:235:20)

Nuke SAUCE_CONNECT_VERSION, the same command works, though

SAUCE_CONNECT_DOWNLOAD_ON_INSTALL=true npm install

It seems that the sc/sauce connect binary by default writes a logfile to /tmp/sc.log - unless a different location is specified.

This is problemantic when operating in a multi-user environment as sc fails to launch if doesn't have write-permissions to the file (e.g. if a different user created it and didn't remove it).

My suggestion would be to create a dynamic logfile path (e.g. /tmp/sc-USERNAME-PID.log) and pass it into sc.

Hello,

When using sauce connect, the private key is displayed on the console like this (I added the Xs myself):

Opening local tunnel using Sauce Connect
Starting sc with args: -u XXXXXXX -k XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX --readyfile /tmp/sc-launcher-readyfile
Creating tunnel with Sauce Labs

This is problematic when the logs are public like on travis. The line with args is only useful for debugging and should never be displayed when the verbose option is set to false.

Regards

I might not use it correctly, but i followed the readme instructions and the link to the documentation is a dead link. Can somebody help me, maybe by adding a little code snippet to run a "hello world" test on certain browsers?

I was expecting it to at least print:

"Sauce Connect ready"
"Closed Sauce Connect process"

This is my code

var sauceConnectLauncher = require('sauce-connect-launcher')

var options = {
  username: process.env.SAUCE_USER,
  accessKey: process.env.SAUCE_GUID,
  tunnelIdentifier: process.env.TUNNEL_IDENTIFIER,
  verbose: true,
  verboseDebugging: true,
  vv: true,
  logger: console.log
}

sauceConnectLauncher(options, function (err, sauceConnectProcess) {
  if (err) return console.error(err.message)
  console.log("Sauce Connect ready")
  sauceConnectProcess.close(function () {
    console.log("Closed Sauce Connect process")
  })
})

This is my log

Opening local tunnel using Sauce Connect
Starting sc with args: -u XXXXXXXX -k XXXXXXXX --verbose -vv --readyfile /tmp/sc-launcher-readyfile
13 Feb 20:42:05 - Sauce Connect 4.4.3, build 3212 0edd00b-dirty
13 Feb 20:42:05 - Using CA certificate bundle /etc/ssl/certs/ca-certificates.crt.
13 Feb 20:42:05 - Using CA certificate verify path /etc/ssl/certs.
13 Feb 20:42:05 - *** WARNING: open file limit 4096 is too low!
13 Feb 20:42:05 - *** Sauce Labs recommends setting it to at least 8000.
13 Feb 20:42:05 - Starting up; pid 23166
13 Feb 20:42:05 - Command line arguments: /home/serapath/Desktop/dev/holding/orgs/fairydust.agency/projects/ethereum-project/browser-solidity/node_modules/sauce-connect-launcher/sc/sc-4.4.3-linux/bin/sc -u fairydust.work -k **** --verbose -vv --readyfile /tmp/sc-launcher-readyfile
13 Feb 20:42:05 - Log file: /tmp/sc.log
13 Feb 20:42:05 - Pid file: /tmp/sc_client.pid
13 Feb 20:42:05 - Timezone: CET GMT offset: 1h
13 Feb 20:42:05 - Using no proxy for connecting to Sauce Labs REST API.
13 Feb 20:42:06 - Resolving saucelabs.com to 162.222.75.243 took 2944 ms.
13 Feb 20:42:07 - Started scproxy on port 48033.
13 Feb 20:42:07 - Please wait for 'you may start your tests' to start your tests.
Creating tunnel with Sauce Labs
13 Feb 20:42:07 - Starting secure remote tunnel VM...
13 Feb 20:42:14 - Secure remote tunnel VM provisioned.
13 Feb 20:42:14 - Tunnel ID: 224ca5148d634cf384d2792c5b80da4b
13 Feb 20:42:15 - Secure remote tunnel VM is now: booting
13 Feb 20:42:17 - Secure remote tunnel VM is now: running
13 Feb 20:42:17 - Using no proxy for connecting to tunnel VM.
13 Feb 20:42:17 - Resolving tunnel hostname to 162.222.75.76 took 60ms.
13 Feb 20:42:17 - Starting Selenium listener...
13 Feb 20:42:17 - Establishing secure TLS connection to tunnel...
13 Feb 20:42:17 - Selenium listener started on port 4445.
13 Feb 20:43:31 - Cleaning up.
13 Feb 20:43:31 - Removing tunnel 224ca5148d634cf384d2792c5b80da4b.
13 Feb 20:43:36 - All jobs using tunnel have finished.
13 Feb 20:43:36 - Waiting for the connection to terminate...
13 Feb 20:43:37 - Connection closed (8).
13 Feb 20:43:37 - Sauce Connect could not establish a connection.
Sauce Connect API failure
13 Feb 20:43:37 - Please check your firewall and proxy settings.
13 Feb 20:43:37 - You can also use sc --doctor to launch Sauce Connect in diagnostic mode.
13 Feb 20:43:37 - Goodbye.
13 Feb 20:43:37 - Sauce Connect could not establish a connection.

The error occured when installing the https://github.com/ripple/ripple-lib
Here is the npm-debug.log
test.txt

Hi,

I've stumbled over these lines:

and:
https://github.com/bermi/sauce-connect-launcher/blob/078d1b53c6760c1004ca9088e9481b12e18f66eb/lib/sauce-connect-launcher.js#L206-210

When I see this correctly this "tunnel ready" callback isn't used internally and can't be used from outside.
Now I really would like to be notified when the Tunnel is ready, to run my (Galen) Tests against Sauce Labs and I don't see any opportunity to do so.

Is there any reason that the callback is triggered after the async.waterfall sequence and not when the tunnel is ready?

I'd like to create a Pull Request where I

• either pass the "tunnel ready" callback within the options
• pass the allready given callback here with async.apply(run, options, callback)
• or pass an aditional callback to the downloadAndRun method (which is kind of ugly, because of the custom "pattern matching")

what would you prefer or am I missing something?

UPDATE:

When I take a look at the example and the code, I'm pretty much sure, that this is a bug and my proposal 2 is meant.

var sauceConnectLauncher = require('sauce-connect-launcher');

sauceConnectLauncher({
  username: 'bermi',
  accessKey: '12345678-1234-1234-1234-1234567890ab'
}, function (err, sauceConnectProcess) {
  if (err) {
    console.error(err.message);
    return;
  }
  console.log("Sauce Connect ready");

  sauceConnectProcess.close(function () {
    console.log("Closed Sauce Connect process");
  })
});

See https://saucelabs.com/docs/connect#connect-flags . These will allow faster loading tests.

 -D,--direct-domains        Comma-separated list of
                            domains. Requests whose host
                            matches one of these will be
                            relayed directly through the
                            internet, instead of through
                            the tunnel.
 -F,--fast-fail-regexps     Comma-separated list of
                            regular expressions. Requests
                            matching one of these will
                            get dropped instantly and
                            will not go through the
                            tunnel.

when the java process is spawned there is not possibility to add the -Dhttps.protocols option like so

java -jar -Dhttps.protocols='SSLv3,SSLv2Hello'

https://saucelabs.com/docs/connect

Could this be added?

When installed globally, write permission problems are encountered when executed as a regular user because it's trying to write to (on Linux):

/usr/lib/node_modules/intern/node_modules/sauce-connect-launcher/lib/readyfile

Perhaps the readyfile could be written to the OS' tmp directory and a temporary filename.

Like discut in

• https://github.com/Polymer/wct-sauce/issues/5
• https://github.com/Polymer/web-component-tester/issues/140

Not use Http request to download plugins but use the npm registry mecanim by putting them in the heroku registry.

That will permit to secure, cache and accelerate the installation procedure (thank to enterprise npm registry).

That permit to be used in company with Business Continuity Plan (BCP) constraint or behind a corporate firewall.

#60 looks like a nice addition, any chance to release that?

https://saucelabs.com/downloads/sc-4.3.9-linux.tar.gz SHA1: 2ee561d16069f20f09fe22bf27e93d658f24d23a
https://saucelabs.com/downloads/sc-4.3.9-linux32.tar.gz SHA1: 285924db00bac5038f0a0d20b6c334b1c55b2570
https://saucelabs.com/downloads/sc-4.3.9-osx.zip SHA1: b15857b60c8b6e1105a241c9faebd7896192c1e0
https://saucelabs.com/downloads/sc-4.3.9-win32.zip SHA1: 1d397d58692fbe8585a0fac66f8dfa5de5dc2c12

Not sure if I'm doing it right, but the tunnel appears to open properly and then immediately shuts itself down (cleanly). How do I leave it open while I spawn karma tests?