Proxy argument not getting passed to SC

[enriquegh]

Short summary of what the user sees: As a user I want to pass the proxy argument to SC so I can have SC be set up with a proxy. Currently we filter this out which makes passing a proxy to SC impossible

Exact steps to reproduce the problem:

1. Clone: https://github.com/enriquegh/node-saucelabs-proxy-bug
2. Run:

npm install

and then:

node start-sc.js

See something like:

2022-04-25 17:35:18.027 [84029] [CLI] [Info] Command line arguments: /Users/enriquegonzalez/projects/node-saucelabs-proxy-bug/node_modules/saucelabs/build/sc-loader/.sc-v4.7.1/bin/sc --verbose --logfile=- --tunnel-name=my-sauce-tunnel --proxy-tunnel --user=enriquegh --api-key=**** --region=us-west

and notice no --proxy flag is included.

Isolation: What must be true for it to happen? When does it not happen? Happens when passing the proxy key. It happens both on CLI and using it as a package.

Links to Relevant Test Archives or Logs: N/A

What attempts were made to find the root cause so far? This happens due to the fact that --proxy is included here: https://github.com/saucelabs/node-saucelabs/blob/9c9f90ca8fa0030d236c697b43a28324b85b3e6f/src/constants.js#L141 which is then added: https://github.com/saucelabs/node-saucelabs/blob/9c9f90ca8fa0030d236c697b43a28324b85b3e6f/src/constants.js#L300

and therefore removed before getting sent to SC.

At first I thought that doing something like:

const CLI_PARAM_KEYS = CLI_PARAMS.map((param) => param.name).filter((name) => name != 'proxy')
const CLI_PARAM_ALIASES = CLI_PARAMS.map((param) => param.alias).filter(Boolean).filter((name) => name != 'p')

which would remove them from the lists and therefore keep them before sending them to SC.

The problem is that when the proxy is used to create a proxy agent for got it expects it to be a proper URL (e.g. http://localhost:8889) whereas SC expects this to be a domain with a port (e.g. localhost:8889)

Given this, I think there are two ways to go about this:

1. Do some magic so that you pass in a proper URL to --proxy/proxy object and it transforms it to how SC expects it. Pros with this approach are that we have the same flag for both REST API calls as well as SC startup. Cons is that this will add complexity to the source code.

2. Create a separate flag like --sauceconnect-proxy that exclusively passes it to SC. Pros are that we keep the code clean. Cons that it will be confusing to customers since this is not a SC flag.

I'm tempted to go with 1. but wanted someone else's input on this

[boneskull]

@enriquegh 1 sounds fine to me.

[enriquegh]

Cool. That's what I was thinking too. I'll get that going.