(1.39.0) ENV variables are not persisting when set from a pipeline

[nboxill]

Is there an existing issue for this?

• I have searched the existing issues and didn't find mine.

Steps to reproduce

Run maestro test on a flow from a gitlab pipeline - using a shell-script installed runner on the host machine.

Actual results

I have a niche use-case with maestro, with my app i'm using a shell-script gitlab runner to run test flows said runner, on a host machine.

Env variables are set from a pipeline:

- export MAESTRO_TEST_EMAIL="$TEST_EMAIL"

CLI 1.38.1

- inputText: ${MAESTRO_TEST_EMAIL} works

CLI 1.39.0

- inputText: ${MAESTRO_TEST_EMAIL} returns null

Expected results

Expect the env variables to persist in maestro tests when set from a gitlab pipeline.

About app

App is a native android application

About environment

MacOS Sonoma

Logs

Logs

<!-- Replace this line with your logs. *DO NOT* remove the backticks! -->

Maestro version

1.39.0

How did you install Maestro?

install script (https://get.maestro.mobile.dev)

Anything else?

N/A

[linear]

MA-2369 (1.39.0) ENV variables no longer working when set from a pipeline

[arancauchi]

Seeing the same issue

[freak4pc]

We're experiencing the same issue

[Fishbowler]

I've recreated this in a simple example.

https://github.com/Fishbowler/maestro-examples/tree/env_vars/env-vars

(I regret naming the folder and branch the same - sorry about that)

Running run.sh gives:

Running on emulator-5554                                                        
                                                                                
 ║                                                                              
 ║  > Flow: flow                                                                
 ║                                                                              
 ║    ✅   Run test.js                                                          
 ║         Log messages:                                                        
 ║           Running test.js                                                    
 ║           MAESTRO_EXAMPLE: undefined                                         
 ║           The env var $MAESTRO_EXAMPLE should be 'potato' but it is not      
 ║    ✅   Run test.js                                                          
 ║         Log messages:                                                        
 ║           Running test.js                                                    
 ║           MAESTRO_EXAMPLE: undefined                                         
 ║           The env var $MAESTRO_EXAMPLE should be 'potato' but it is not      
 ║    ✅   Run ${console.log('MAESTRO_EXAMPLE:' + MAESTRO_EXAMPLE)}             
 ║         Log messages:                                                        
 ║           MAESTRO_EXAMPLE:$MAESTRO_EXAMPLE 

Log file: maestro.log

[woytekn]

Same here.
The issue has been solved after using 1.38.1 version in the pipeline

[debsouto]

Any updated regarding this issue? When we use the command export MAESTRO_VERSION=1.38.1 it seems to work fine ONLY if used together with curl -Ls "https://get.maestro.mobile.dev" | bash after. if we remove the command to update Maestro (even tough we settled the correct version) it seems to be masking the emulator boot

[DanielPritchard]

I just spent a day trying to debug why this was not working, I have had to downgrade to 1.38.1 to get my tests running again

[Fishbowler]

Locally, I'm working around this in v1.39.1 by passing them tiresomely at the CLI.

e.g. For the OP's example, maestro test -e MAESTRO_TEST_EMAIL=$MAESTRO_TEST_EMAIL myFolderOfFlows

[arancauchi]

Be aware that for env vars passed to maestro they need a preceding -e before each key/value pair (the docs don't state this).
If expanding from a .env file you can use:

env_vars=$(cat .env | sed 's/^/-e /' | xargs)
maestro test $env_vars

[Fishbowler]

A quick conversation in Slack with Mário Raček set me onto a key difference: running an individual flow accurately captures variables from the environment. Running a folder does not. This offers a key avenue for investigation in the CLI codebase ❤️

[Fishbowler]

This fix will be included in the next CLI release.
Thanks to @nboxill for reporting, and to @mario-racek-devnautica for finding the important differences that led to the fix.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar problem, please file a new issue. Make sure to follow the template and provide all the information necessary to reproduce the issue.
Thank you for helping keep us our issue tracker clean!