Summary:
This global is used in tests, to keep track of how many jobs run at
once. Jobs are supposed to increment it when they start and decrement it
when they finish. But if the plugin returned an error code, we were
throwing and failing to decrement that code.
This didn't repro for me locally, because the only tests that checked
the counter were happening early in my test run, but it caused Travis
failures because of a quirk in test run order.
This diff fixes the issue by putting the decrement in a finally clause,
and it extends the plugin tests so that all of them sanity check this
counter.
Reviewers: sean
Reviewed By: sean
Differential Revision: https://phabricator.buildinspace.com/D130
Summary: That was a python3.2 compatibility function. Now we're only >=3.3.
Test Plan: Ran `test.sh` inside a 3.3 virtualenv.
Reviewers: sean
Differential Revision: https://phabricator.buildinspace.com/D83
Summary:
Finally write some tests that check how much parallelism is actually
going on. I initially wrote D74 to help, but that was way more
complicated than it needed to be. Instead, just count to a global
variable in `plugins.py` and write tests against that variable.
Several cases get exercised here:
- Parallelism works at all.
- `--jobs 1` turns off parallelism.
- Identical modules don't get fetched in parallel.
- Modules with the same plugin cache dir don't either.
For that last case, create the `noop_cache` plugin, which doesn't
actually do anything besides defining `cache fields` in its
`plugin.yaml`.
Test Plan:
For each of our locks (the module cache lock, the plugin cache lock, and
the parallelism semaphore), delete it, and confirm that a different test
fails each time. Also, set `DEFAULT_PARALLEL_FETCH_LIMIT` to 1 and
confirm that the first test fails.
Reviewers: sean
Differential Revision: https://phabricator.buildinspace.com/D79
Jack O'Connor