The test `test_proxy_gateway_setup_nodes` makes sure that 2 execnet
gateways are created, but only one node is allocated.
The test `test_proxy_gateway` tries to run a test on a proxy.
Proxy gateways do not run workers, and are meant to be passed with the
`via` attribute to additional gateways.
They are useful for running multiple workers on remote machines.
Example usage:
```
pytest -sv --dist=load --px "id=my_proxy//socket=IP:PORT" --tx "5*popen//via=my_proxy"
```
Proxy gateways do not run workers, anda re meant to be passed
Either unschedule all requested tests, or none if it's not possible -
if some of the requested tests have already been processed by the time
the request arrives. It may happen if the worker runs tests faster than
the controller receives and processes status updates. But in this case
maybe it's just better to let the worker keep running.
This is a prerequisite for group/scope support in worksteal scheduler -
so they won't be broken up incorrectly.
This change could break schedulers that use "steal" command. However:
1) worksteal scheduler doesn't need any adjustments.
2) I'm not aware of any external schedulers relying on this command yet.
So I think it's better to keep the protocol simple, not complicate it for
imaginary compatibility with some unknown and likely non-existent
schedulers.
Co-authored-by: Bruno Oliveira <nicoddemus@gmail.com>
Use the execnet main_thread_only execmodel so that code which expects
to run in the main thread will just work. This execmodel has been
merged to the execnet master branch via pytest-dev/execnet#243, so this
patch should not be merged until there is a released version of execnet
supporting the main_thread_only execmodel.
Closes#620
Currently, a reason to terminate early (e.g. test failure with --exitfail
option set) causes DSession to immediately raise an Interrupt exception.
Subsequent reports generated by the workers, during the shutdown phase, are
discarded.
One consequence is that, for the failing test, teardown and testfinish are
ignored, which prevents corresponding hooks pytest_runtest_logreport and
pytest_runtest_logfinish being executed for the failing test (this problem
covered in #54). The reporting of tests executing in other workers is also left in an
indeterminate state. This can affect other plugin code.
This is a relatively simple fix, which appears to have minimal and, I think,
acceptable impact on text execution behaviour.
The observable differences are differences in what is reported about a test
run. For example, when running, for example with the '-x/--exitfail' option, it
is possible that more than a single test failure is reported. This is because
more than one test did fail before the test run was completely stopped. The
reporting is absolutely correct; and complete. Prior to this change, only a
single failure would have been reported, but because of incomplete and arguably
incorrect reporting.
Maximum number of tests scheduled in one step.
Setting it to 1 will force pytest to send tests to workers one by one -
might be useful for a small number of slow tests.
Larger numbers will allow the scheduler to submit consecutive chunks of tests
to workers - allows reusing fixtures.
Unlimited if not set.
Fixes#855Fixes#255
Otherwise we would get this error:
```
error: Function "Callable[[Any, bool, Optional[float]], None]" could always be true in boolean context [truthy-function]
```
* drop empty setup.py which "breaks" on incomplete build envs
* use the build package to build the dist
* update the gh workflow to use it
fixup noise from pre-commit
* Get `-nauto` default from `PYTEST_XDIST_AUTO_NUM_WORKERS`
A few additional tests for existing functionality are added too.
And the ``-n logical`` option is documented.
Fixes: https://github.com/pytest-dev/pytest-xdist/issues/792
* Restore old initial batch distribution logic in LoadScheduling
pytest orders tests for optimal sequential execution - i. e. avoiding
unnecessary setup and teardown of fixtures. So executing tests in consecutive
chunks is important for optimal performance.
Commit 09d79ace35 optimized test distribution for
the corner case, when the number of tests is less than 2 * number of nodes.
At the same time, it made initial test distribution worse for all other cases.
If some tests use some fixture, and these tests fit into the initial batch,
the fixture will be created min(n_tests, n_workers) times, no matter how many
other tests there are. With the old algorithm (before
09d79ace35), if there are enough tests not using
the fixture, the fixture was created only once.
So restore the old behavior for typical cases where the number of tests is
much greater than the number of workers (or, strictly speaking, when there
are at least 2 tests for every node).
In my test suite, where fixtures create Docker containers, this change reduces
total run time by 10-15%.
This is a partial revert of commit 09d79ace35
Co-authored-by: Bruno Oliveira <nicoddemus@gmail.com>
