-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to configure run_tests via environment variables #197
Comments
Sounds reasonable, yes. |
this seems related to https://github.com/matthew-brett/multibuild/issues/183, although there the OP wants to conditionally set the variable for the build phase, whereas I want to do it for the test phase. I imagine that if I wish to set the TOXENV in the Travis build env and have it available in the I wonder... if this "inherit the whole Travis environment from within the docker build and test run" could actually be a feature of multibuild. If you think about it, the macos builds already work like that, because of the mere fact that they don't run in an isolated docker container. |
I did think about that, but it's not easy to work out which vars should go in, and which are coincidental to the bash shell running on travis. |
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 therun_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 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_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 intravis_linux_steps.sh
could pass-e ENV_VARS_PATH="$ENV_VARS_PATH"
option to thedocker run
command, and thendocker_test_wrap.sh
could perform asource $ENV_VARS_PATH
.What do you think?
The text was updated successfully, but these errors were encountered: