Currently it isn't possible to set environment variables in the .travis.yml and have those propagate down to the install_run phase of multibuild, at least for the linux platform.
One use case is for setting the TOXENV variable in the Travis build matrix, and have the run_tests function run the corresponding tox environment.
The workaround I'm using now is to define the tox environment inside run_tests function based on the value of MB_PYTHON_VERSION, which is the only variable that trickles down from the Travis env down to the matthewbrett/trusty docker container where the linux run_tests is being run.
One way to do this could be to reuse the env_vars.sh trick that multibuild already uses to pass environment variables to the dockerized manylinux build stage.
The install_run function in travis_linux_steps.sh could pass -e ENV_VARS_PATH="$ENV_VARS_PATH" option to the docker run command, and then docker_test_wrap.sh could perform a source $ENV_VARS_PATH.
What do you think?
Currently it isn't possible to set environment variables in the .travis.yml and have those propagate down to the
install_runphase of multibuild, at least for the linux platform.One use case is for setting the
TOXENVvariable in the Travis build matrix, and have therun_testsfunction run the corresponding tox environment.The workaround I'm using now is to define the tox environment inside
run_testsfunction based on the value ofMB_PYTHON_VERSION, which is the only variable that trickles down from the Travis env down to the matthewbrett/trusty docker container where the linuxrun_testsis being run.One way to do this could be to reuse the
env_vars.shtrick that multibuild already uses to pass environment variables to the dockerized manylinux build stage.The
install_runfunction intravis_linux_steps.shcould pass-e ENV_VARS_PATH="$ENV_VARS_PATH"option to thedocker runcommand, and thendocker_test_wrap.shcould perform asource $ENV_VARS_PATH.What do you think?