Skip to content

Isolate tests and run concurrently #1159

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

Merged
merged 30 commits into from
Aug 27, 2013

Conversation

dstufft
Copy link
Member

@dstufft dstufft commented Aug 22, 2013

  • Shadows the py.test tmpdir fixture with our own that returns a tests.lib.path.Path object.
  • Adds a virtualenvfixture which creates a virtual environment in the per test temporary directory.
  • Adds a script fixture which creates an instance of PipTestEnvironment using the per test virtual environment.
  • Adds a data fixture which copies all of the test data into the per test temporary directory so tests can interact with it.
  • Instead of checking out to a shared tests_cache directory the helpers local_repo and local_checkout now cache to a per test specific temporary directory.
  • Remove monkeypatching setuptools on travis and simply upgrade setuptools prior to running the tests
  • Enables concurrent builds on all Pythons except for 3.2.

The bulk of the work of this PR is in isolating the tests from each other. To do that it uses the py.test tmpdir to give each test a unique temporary directory and then moves all of the operations that modify the filesystem in any way to take place inside of that temporary directory. It adds some other fixtures and modifies some helpers along the way to make doing that a bit nicer.

The easiest part of the PR was enabling the actual concurrent builds. We use 8 concurrent builds because that seems to give us the most bang for the buck without making PyPy dreadfully slow (I'm unsure of why but using 16 processes made PyPy take twice as long as 8 processes). However I was unable to use concurrent builds on Python 3.2 because of an apparent bug in py.test or pytest-xdist. I will follow up with upstream to attempt to sort out why 3.2 was erroring out and then submit another PR to enable concurrent builds for it. This means PRs still take awhile to pass but at least there is some quick feedback.

image 2013 08 24 8_55_53 am

@pnasrat
Copy link
Contributor

pnasrat commented Aug 25, 2013

Awesome job

dstufft added 29 commits August 27, 2013 06:41
* Uses the same generation method as the built in tmpdir, simply
  returns a different object type.
* We've selected a concurrency number of 16 because that's how
many CPUs the multiprocessing library tells us a Travis box has.
This is needed because the various activities that exericsing the
tests do will cause files to change inside this data directory. If
we do not make it test specific then we run into concurrency issues.
Previously pip was always installed directly from the source tree
however this causes concurrency issues so it is now copied into
the temporary directory and installed from there.
There seems to be some issues with parallel tests and Python 3.2
in pytest or pytest-xdist, so we run the tests normally for now
on 3.2.
dstufft added a commit that referenced this pull request Aug 27, 2013
@dstufft dstufft merged commit fe3d37b into pypa:develop Aug 27, 2013
@dstufft dstufft deleted the isolate-tests-and-run-concurrently branch August 27, 2013 11:47
@@ -20,4 +24,4 @@ branches:
- 1.3.X
- 1.4.X
env:
- PIP_USE_MIRRORS=true
- PYTHONHASHSEED=0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does this apply? 0?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Python 3.3+ hash randomization is on by default, this confuses pytest-xdist. Setting the hash seed to zero effectively disables hash randomization.

See https://bitbucket.org/hpk42/pytest/issue/346/pytest-xdist-and-python-33-is-sort-of

@qwcode
Copy link
Contributor

qwcode commented Aug 27, 2013

merge 👍 ex post facto

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants