[QUESTION] Update browserstack blog post example for Maestro version

[LeunensMichiel]

Question

Hi! 👋

I’m looking to upgrade our E2E workflows to use Maestro while continuing to leverage our existing tooling (BrowserStack). I came across this package and it looks like a great way to make that possible.

While researching, I read a couple of your blog posts:

• https://devicelab.dev/blog/run-maestro-flows-any-cloud
• https://devicelab.dev/blog/browserstack-maestro-guide#summary

From these posts, it seems fairly straightforward to run Maestro on BrowserStack using this setup. However, both examples rely on commands that mention BrowserStack only supporting Maestro 1.39.

I double-checked the BrowserStack documentation and, while their docs are a bit sparse, I found this page which states that you can specify the Maestro version to use:
https://www.browserstack.com/docs/app-automate/maestro/set-up-test-env/configure-tests/set-maestro-version

Given that this package runs tests on BrowserStack via the maestro-runner CLI, I’m wondering how that configuration would work here. I couldn’t find any CLI flag or code path that allows specifying the Maestro version for BrowserStack.

Am I missing something, or is this currently not supported by the package?

Thanks! 🙏

[omnarayan]

@LeunensMichiel — just to clarify, BrowserStack has their own Maestro integration, but that's a completely different thing from maestro-runner.

What we're doing here is different — we're letting you run Maestro test cases through Appium without changing a single line in your test cases. The write-up explains it better:
https://devicelab.dev/blog/run-maestro-flows-any-cloud

The reason this exists: a lot of providers (like Sauce Labs) don't support Maestro at all, and BrowserStack's support is quite outdated. This approach lets you leverage existing Appium infrastructure to run Maestro flows on any cloud provider.

People are already using it with BrowserStack/Saucelab/Testingbot/localappiu, this way. Not sure if you're trying to run via Appium — if not, then we might be solving different problems. Either way, here's a working TestingBot example to give you a concrete idea of how it works (BrowserStack is the same, just different URL and caps):
https://github.com/devicelab-dev/maestro-runner/blob/main/docs/cloud-providers/testingbot.md

[LeunensMichiel]

Hi! Testing it out with our current Browserstack subscription.

Initial findings is that its indeed super fast, congrats! My tests failed to run on android though. I got the following error:

✗ launchApp (clearState) (260ms)
╰─ Failed to clear app state: (my apps id)

Did it with:

appId: ${APP_ID}
---
- launchApp:
      clearState: true

command: maestro-runner --driver appium --appium-url "https://hub-cloud.browserstack.com/wd/hub" --caps ./flows/capabilities-android.json test -e APP_ID="whatever_app_id" flows/

[LeunensMichiel]

Okay so I got it running on ios. One issue that is not correct from the docs:

• I had to remove clearState from the yaml, because I would get the following error on BS: [W3C (fdfd88fa)] Encountered internal error running command: UnknownCommandError: Unknown mobile command 'clearApp'
• I now have to do the following which I don't like because my test should be working for both ios and android. In the background, the appium driver should ignore the clearState param when newSession is set. And the other way around for Android.

- launchApp:
      newSession: true
    #   clearState: true

Next up: Our app uses bluetooth and location permissions on launch. (Map based). On maestro, by default it accepts all permissions, but I saw in browserstack that the app doesn't get past the initial logic.

I've tried:

• setting bs:options.autoAcceptAlerts: true
• setting permissions.all: unset and then use - acceptAlert. But still no luck unfortunately. I also got the error unsupported step type: *flow.AcceptAlertStep then

Sorry for the bug reports! I'd really like to use maestro runner but had no luck so far setting it up correctly 😅