expo
feat: generate params for maestro based on envs
Why
This change enables secure and flexible test configuration by allowing dynamic environment variables to be passed to Maestro flows via command-line parameters. This addresses the need to:
- Avoid hardcoding sensitive values like credentials in test files (GitHub/community discussions around secure test configuration)
- Support environment-specific configurations in CI/CD pipelines
- Align with Maestro's parameter handling best practices (documentation reference)
Example Scenario
Injecting API keys dynamically in CI:
build:
name: Build and Run Secure Tests
steps:
- eas/build
- eas/maestro_test:
inputs:
flow_path: .maestro/auth-tests/flow.yaml
env:
AUTH_API_KEY: ${PROD_API_KEY} # From CI secrets
Corresponding Maestro flow (.maestro/auth-tests/flow.yaml):
appId: com.example.app
jsEngine: graaljs
---
- evalScript: ${console.log("API Key:", AUTH_API_KEY);}
How
Implemented support for passing environment variables through -e flags following Maestro's external parameters pattern
Test Plan
yarn test src/steps/functionGroups/__tests__/maestroTest.test.ts
Hey, thanks. Wouldn't it be easier to use MAESTRO_* variables that are automatically exposed within the flow?
https://maestro.mobile.dev/advanced/parameters-and-constants#accessing-variables-from-the-shell
I see one problem which is that we currently don't apply templating/interpolation to env step attribute, but this is something we're planning to do soon either way. Then, instead of having two env on a call to eas/maestro_test (top-level and under inputs) you'd do (in a Custom Build):
build:
name: Build and Run Secure Tests
steps:
- eas/build
- eas/maestro_test:
env:
MAESTRO_AUTH_API_KEY: ${ eas.env.PROD_API_KEY } # From CI secrets
inputs:
flow_path: .maestro/auth-tests/flow.yaml
On a separate note I would recommend considering moving to EAS Workflows. You could orchestrate multiple builds on different platforms, run Maestro tests conditionally, use different EAS Environments for different jobs and lots more.
