You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current behaviour of --env SOME=THING appears to not set environment variables "in" the device when launching a test (as is supported by xcodebuild-run tests). I can see USER, XPC_FLAGS, XPC_SERVICE_NAME and others, but additional --env-provided values seems to be broken.
Desired behavior
The expected behaviour is that using saucectl's --env SOME=THING cli option would set environment variables on the target as is being done by xcodebuild-driven testsé
Config to reproduce
Run any iOS xcuiapplication-based tests that print out the whole environment. Example code to do that in a setup method:
@alexplischke based on the above foreach loop, I still think there could be a backend change that would allow at least iOS env settings to be passed (as xcodebuild allows that locally). For the immediate term, I unfortunately might go with your suggestion, but on the long run this should be fixed in some way.
Current behavior
The current behaviour of
--env SOME=THING
appears to not set environment variables "in" the device when launching a test (as is supported by xcodebuild-run tests). I can see USER, XPC_FLAGS, XPC_SERVICE_NAME and others, but additional--env
-provided values seems to be broken.Desired behavior
The expected behaviour is that using saucectl's
--env SOME=THING
cli option would set environment variables on the target as is being done by xcodebuild-driven testséConfig to reproduce
Run any iOS xcuiapplication-based tests that print out the whole environment. Example code to do that in a setup method:
Versions
0.59.x
The text was updated successfully, but these errors were encountered: