https://pantsbuild.org/ logo
Join Slack
Powered by
How would I control `test` to run serially for som...
# general
h
How would I control 
test
to run serially for some specially marked tests? I don't see anything in https://www.pantsbuild.org/docs/reference-test or https://www.pantsbuild.org/docs/reference-pytest for an option on that. We have integration tests that have to run against shared hardware and running in parallel would cause lots of issues.
c
Pending a better answer, I suppose you could run it as 
./pants test --debug …
to force it to run in the foreground, and thus not in parallell. https://www.pantsbuild.org/docs/reference-test#section-debug
w
you can also use https://www.pantsbuild.org/docs/reference-pytest#section-execution-slot-var to have a unique execution slot inserted into the test run as an environment variable, if you have N instances of the test hardware, for example
it won’t bound the total concurrency of the tests though.
h
N is 1 in our case. I don't think I understand the execution slot meaning from the docs.
w
mm, sorry about that. if process parallelism is set to 8, then there are 8 slots that can be in use at a time. each of them is assigned an id, and that environment variable exposes that id
so… you could also reduce the parallelism for some of your tests (by setting 
--process-execution-remote-parallelism=1
), rather than setting 
test --debug
. but it would still need to be in a separate run of pants (probably after the first, so that you hit caches populated in the first run)
h
So maybe the run would look something like 
./pants --process-execution-local-parallelism=1 test path/to/my/integration/tests:: --pytest-args="--integration"
. So first options keeps things serial and second option selects my custom markers that I can 
pytest.mark
with. Thoughts?
w
yea, basically. the option affects all processes that we run though: hence the suggestion to run any parallel/non-integration tests that you have first to warm caches as much as possible.
if that’s awkward, i could imagine an API where tests could be marked “foreground” or “exclusive” or something, which would force them to run 1) locally, 2) exclusively… if you’d like to open a ticket about it, i can hook it up to some related efforts.
➕ 1
h
Yup, that makes sense to me. I'll think on the specific ask before opening a ticket. I think having some kind of flag that's more directly related to the test goal might be nice.
👍 1
5 Views
Open in Slack
PreviousNext
Powered by