Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: BrowserStack\Local does not pass along binary_path to BrowserStack\LocalBinary #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mparker17
Copy link

@mparker17 mparker17 commented Apr 15, 2022

One of the arguments accepted by BrowserStack\Local is binaryPath. You're supposed to be able to pass the path to an already-downloaded BrowserStackLocal binary.

However, currently, when you call BrowserStack\Local::start(...)....

  1. it creates an instance of BrowserStack\LocalBinary. The BrowserStack\LocalBinary constructor creates its own list of places to look for the local binary.
  2. When it subsequently calls BrowserStack\LocalBinary::binary_path(), that searches the list of possible binary locations (which currently does not include the binaryPath you passed to BrowserStack\Local), and if it fails to find one in those locations, it downloads one.

This patch changes BrowserStack\Local::start(...) so that, if binaryPath has been set, it adds binaryPath to the top of BrowserStack\LocalBinary list of possible binary locations before it calls BrowserStack\LocalBinary::binary_path().


You would run into this problem if you're trying to run a BrowserStackLocal inside a Docker container whose image is based on Alpine Linux... which you might do if you're running automated BrowserStack tests in GitHub Actions or GitLab CI/CD.

Basically, Alpine Linux uses the musl library, instead of glibc, so binaries (e.g.: BrowserStackLocal) linked against glibc on "traditional" Linux systems usually don't run on Alpine; and vice-versa. Since BrowserStackLocal v8.1, BrowserStackLocal is available for 64-bit Alpine/musl systems, but it's (rightly) not the default download.

Trying to run a BrowserStackLocal binary linked against glibc when there's only musl available results in a silent failure... Linux can run the ELF binary but it does nothing (except abort with an exit-code indicating failure) because the symbols it was linked against do not exist.

This brings some user stories for this ticket...

As a DevOps being charged pipeline minutes by my CI/CD provider
I want to be able to prepare my own Docker image with the BrowserStackLocal binary already downloaded
So that I don't have to spend pipeline minutes having BrowserStack\BrowserStackLocal download another copy to a different location

... and ...

As a DevOps working on an Alpine/musl-based Linux
I want to be able to pass the path to a musl-linked BrowserStackLocal to BrowserStack\Local
So that my pipeline doesn't silently fail when BrowserStack\BrowserStackLocal downloads the glibc-linked BrowserStackLocal instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant