parallel invocation of tox environments #439 #1102
Conversation
gaborbernat
force-pushed
the
parallel
branch
3 times, most recently
from
f059f7c
to
bc134c8
Compare
When tests are executed using Tox in parallel, modify the test database names, to avoid name collisions between processes. This change renames the existing `django_db_modify_db_settings_xdist_suffix` fixture, to a generic `django_db_modify_db_settings_parallel_suffix` one, in case more scenarios/tools have to be considered in the future. It also handles projects where both `pytest-xdist` and parallel `tox` are being using, generating database names like `test_default_py37-django21_gw0`. **Notes**: * WIP at the moment, until `tox` decides how to expose that it's running in parallel. (Current WIP pull request on their side [0]) * This could break an existing contract for the `django_db_modify_db_settings_xdist_suffix`, depending on projects using it directly. Probably, we want to avoid a major release just for this fix, so if that fixture is not intended to be used, maybe we're fine? Resolves pytest-dev#678. [0] tox-dev/tox#1102
|
Hi @gaborbernat ! I'm currently working on adding support to For this scenario at least, it would be great to have a public-facing way to check if Tox is running in parallel or not. The |
|
Sure we can add some environment variable, but I believe shouldn't two parallel pytest invocations work always, even if not made through tox, aka parallel shell invocations? |
|
I'm not sure we would like to rename DBs by default, even in projects that won't run in parallel or have other requirements/limitations for test DB generation. For two parallel However, to support scenarios where That way, even if developers aren't using |
|
I'm not sure I follow why always adding the PID is a bad thing🤔 |
I also think that this could be useful as a public facing env var. About the name: I think it would be good to always have |
|
Utilising subprocess is a great idea I think, as it just seems glaringly obvious rather than using gevent or something simlilarly fragile. This will obviously not work for setups with hundreds of environments, but I honestly hope that those are extremely rare anyway and projects with setups like that do not rely on something like |
|
Thinking this through I now actually want to implement some throttling similar to how pytest-xdist has. |
|
Really nice and simple way to "merge" detox into tox, I think. How about also creating an entry point |
|
I tried running tox parallel now locally with tox itself and have the following output: I can't find anything in the logs about the source of the error either :( this might well be a problem with tox itself. I have to admit I hardly ever look into the logs, so I don't even know exactly what I should expect. Would it be feasible to always capture the output and print it out for all failed envs? |
|
This should already happen will need to check why not did in your case. |
Can you post an example output what it looks like when it works? |
|
@obestwalter turns out I did not implement reporting of failed environments, now added it 👍 |
gaborbernat
added
feature:new
gaborbernat
force-pushed
the
parallel
branch
3 times, most recently
from
e1a543e
to
4660bef
Compare
…s does not affect run targets
|
Blocked on https://github.com/tox-dev/detox/issues/40 for now. |
|
Thanks for your patience. I have time tonight and tomorrow to prepare a proper funeral and come up with a plan how to make sure that this will be as painless as possible for everybody involved :) |
|
Thinking about it again: adding detox as command for this new functionality was a BadIdea(TM), so this should not go forward. I'll make a new detox release with an uppper bound for tox and add a warning and that should be it. that new parallel functionality can have a fresh start then without pretending to be something else. |
|
going meta here: |
|
Releasing now via #1134. |
|
I love it ❤️ |
This solution is
subprocessbased. We're already heavily using subprocesses, so I consider this implementation safe.TBD:
Resolves #439.