Tox is a tool for automate testing in Python. It does so by reading
a tox.ini file where we specify the environments we want to test, and it will create a brand new
virtual environment for that setup and run the test suite against it.
Let’s start by installing tox and add it to our requirements.txt file.
As you can see we have a [tox] block in which we defines a list of environments we want to test.
Next, we define some blocks for the different Django versions we want to test. The [testenv] block
defines the command we want to run, and finally we combine the [testenv] with the different version
blocks in order to fire up the test runner.
Another option would be to simply change the Python version, either during the build or on one of the containers in a parallel build. We use pyenv to manage Python versions, so you could do something like this if you are using a single container:
- make test
- pyenv global 2.7.9
- make test
Alternatively, you can test both versions in parallel—e.g. set up a parallel build and make a few build containers run different versions of Python.
We add an env var called $CIRCLE_NODE_INDEX when a build runs with more than one container. This means that you can just make the Python choice with a simple if condition in the dependencies: pre step. Mind that the machine section cannot handle multiple configurations, so you could do something like this:
- if [ $CIRCLE_NODE_INDEX == "1" ] ; then pyenv global 2.7.9 ; fi
- make test: # note the colon
This will configure Python 2.7.9 instead of 2.6.8 only on the second container (index starts at 0).
First of all, thanks for the detailed reply, that is a nice workaround.
But I wouldnt call it a solution. It is a terrible hack.
Are there any plans, to support this scenario directly from circle.yml?
While for a specific end-product this is a rare scenario, a FOSS usually requires testing against different configurations.