Repository navigation
BrowserStack Local version 8.1 is broken in container environments #114
Description
Activity
This problem also exists in the debian-based node:10 container. It seems the log messages are printed to stdout despite the
--daemonflag - 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}}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"}}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
We are looking into this.
Reacted by Paul ScottPlease look into this on priority. Our CI/CD is blocked due to this.
Also blocks our deployment pipeline.
We use Browserstack and WebdriverioIt 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)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.
Reacted by Nimit Aggarwal, Yash Ladha, DrewMoody, Dmitry Munda, Paul Scott, Rutuja Marathe, Schoorens and PromodeHello 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 workWe 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.
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.
Reacted by Filipp Riabchun, Nimit Aggarwal, Andrew Boyton and Paul
Our CI build started to fail due to
browserstack-localthrowing these errors:As these randomly started, I suspect the
BrowserStackLocalbinary 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 instdout, which probably shouldn't be there sincebrowserstack-localexpect valid JSON:I'm running
browserstack-local-nodejsv1.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-localone, instead of the last version of the binary being randomly fetched as it is the case currently, causing CI builds to unexpectedly break.