browserstack/browserstack-local-nodejs

BrowserStack Local version 8.1 is broken in container environments

Opened this issue · 10 comments

laurentgoudet commented

Our CI build started to fail due to browserstack-local throwing these errors:

Connecting BrowserStack local..
undefined:1
Tue Sep 01 2020 14:26:45 GMT+0000 (UTC) -- Container runtime environment detected
^

SyntaxError: Unexpected token T in JSON at position 0
    at JSON.parse (<anonymous>)
    at /root/<foo>/node_modules/browserstack-local/lib/Local.js:59:23
    at ChildProcess.exithandler (child_process.js:295:7)
    at ChildProcess.emit (events.js:196:13)
    at maybeClose (internal/child_process.js:1011:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:268:5)

As these randomly started, I suspect the BrowserStackLocal binary was updated with a broken version, as it doesn't seem to be pinned to a particular one. Manually starting the binary shows log messages in stdout, which probably shouldn't be there since browserstack-local expect valid JSON:

bash-4.4# /root/.browserstack/BrowserStackLocal --version 2>/dev/null
Tue Sep 01 2020 14:31:19 GMT+0000 (UTC) -- Container runtime environment detected
Tue Sep 01 2020 14:31:19 GMT+0000 (UTC) -- Attaching services to public interface
BrowserStack Local version 8.1

I'm running browserstack-local-nodejs v1.4.5 as v1.4.6 is broken as pointed out in 7e73b1f#r41945904, but manually patching v1.4.6 still shows the same issue.

This happens on Alpine Linux within a Docker container, hence the "Container runtime environment detected". The issue seems limited to container environments as running the v8.1 outside a container does not show the logs, and doesn't break browserstack-local.

In the future it would be great if the version of the BrowserStack binary could be pinned to a particular browserstack-local one, instead of the last version of the binary being randomly fetched as it is the case currently, causing CI builds to unexpectedly break.

icio commented

This problem also exists in the debian-based node:10 container. It seems the log messages are printed to stdout despite the --daemon flag - which is meant to output only JSON to stdout.

$ ~/.browserstack/BrowserStackLocal --daemon start 
Tue Sep 01 2020 14:53:03 GMT+0000 (UTC) -- Container runtime environment detected
Tue Sep 01 2020 14:53:03 GMT+0000 (UTC) -- Attaching services to public interface
{"state":"disconnected","pid":111,"message":{"genre":"error","message":"Key is required to start local testing!","bsErrorCode":2001}}
icio commented

It seems --daemon's stdout/stderr have been reversed in the latest release: I was is incorrect - the outputs have not been reversed.

# supress stderr
root@85e473a4b835:/workspace# ~/.browserstack/BrowserStackLocal --daemon start 2>/dev/null
Tue Sep 01 2020 14:54:29 GMT+0000 (UTC) -- Container runtime environment detected
Tue Sep 01 2020 14:54:29 GMT+0000 (UTC) -- Attaching services to public interface

# supress stdout
root@85e473a4b835:/workspace# ~/.browserstack/BrowserStackLocal --daemon start 1>/dev/null
{"state":"disconnected","pid":157,"message":{"genre":"error","message":"Key is required to start local testing!","bsErrorCode":2001}}

Correction: --daemon outputs JSON to stdout/stderr depending on whether it's an error. Successful messages are still printed to stdout:

~/.browserstack/BrowserStackLocal --daemon start --key $BROWSERSTACK_ACCESS_KEY 2>/dev/null
Tue Sep 01 2020 14:58:40 GMT+0000 (UTC) -- Container runtime environment detected
Tue Sep 01 2020 14:58:40 GMT+0000 (UTC) -- Attaching services to public interface
{"state":"connected","pid":180,"message":{"message":"Connected"}}
sschoorens commented

Same here and if you try to update to 1.4.6 version it is also broken so we are blocked in our ci hope it will be fixed soon

bipul21 commented

We are looking into this.

  • 👍1
anandhaprakash-mani commented

Please look into this on priority. Our CI/CD is blocked due to this.

goatsy commented

Also blocks our deployment pipeline.
We use Browserstack and Webdriverio

It shows like this

[browserstack.local] is set to true but local testing through BrowserStack is not connected.

TypeError: this.isAlpine is not a function
    at LocalBinary.getDownloadPath (/home/user/workspace/wdio/node_modules/browserstack-local/lib/LocalBinary.js:21:15)
bipul21 commented

We have reverted both the local binary to 8.0 and reverted this PR #111
We will post a detailed post mortem soon.

Apologies for the inconvenience caused.

  • 👍8
vlashchanka commented

Hello guys! I encountered the same issue on CI side. Are there any plans to add more control to versions management ?
As a final user I would like to have the same version all the time my dependencies are installed. If I am correct about how this module works - it downloads the binary from aws and in case there is a bug there - the pipelines on CI will not work

sschoorens commented

We have reverted both the local binary to 8.0 and reverted this PR #111
We will post a detailed post mortem soon.

Apologies for the inconvenience caused.

Thanks for the fast action the revert work with the package version 1.4.5.

abhishekchoudhary commented

Hi everyone, I am the product manager looking after BrowserStack Local, and I wanted to take second to apologize for the botched deploys yesterday. We've identified the bugs as well as the flaws in our processes which allowed these bugs to be released. We will be deploying new, fixed versions very soon after ensuring that everything works on every platform.

As for pinning these packages to specific versions of the BrowserStack Local binary, that is a completely valid request which we have taken up on our short term roadmap - #115 will help you track our progress.

  • ❤️4