Subprocess.CalledProcessError's __init__ takes 4 arguments out
of which 2 are optional. It is being passed 2 arguments in
zulip_tools.py. However, python 3 stubs are incorrect and only
1 argument has been marked as default.
See https://github.com/python/typeshed/pull/329.
Add '# type: ignore' to that line so that mypy check passes in
python 3 mode.
The subscribers list is appended to in `peer_add` events with not
regard for preserving the ordering, and ordering isn't really
important here, so it seems best to just sort it in these checks.
This works around a nasty problem with Webpack that you can't run two
copies of the Webpack development server on the same project at the
same time (even if on different ports). The second copy doesn't fail,
it just hangs waiting for some lock, which is confusing; but even if
that were to be solved, we don't actually need the webpack development
server running to run the Casper tests; we just need bundle.js built.
So the easy solution is to just run webpack manually and be sure to
include bundle.js in the JS_SPECS entry.
As a follow-up to this change, we should clean up how test_settings.py
is implemented to not require duplicating code from settings.py.
Fixes#878.
This fixes some tracebacks I got while testing the Zulip htpasswd SSO
functionality.
I think that this stopped working as a result of the Jinja2 migration.
Installing `nginx` is problematic, because it means something is using
port 80 and thus `letsencrypt-auto --standalone` doesn't work. But we
do want `openssl` so that the directory trees we create symlinks in
will exist.
Also encode/decode strings appropriately when using api_keys to generate
basic auth header.
Also fix clashing annotations in zerver/tests/test_external.py.
* Add Optional where required.
* Set type of req_redis_key as `(text_type) -> text_type` for consistency.
Almost all our cache keys and redis keys use this signature.
This is important for both ensuring the Nagios checks work correctly
in production, as well as making sure the `zulip` user can access the
virtualenv (owned by the `travis` user) in Travis CI.
Rather than looking at which venvs are used by this particular build,
we instead look at which venvs have a hash that is the hash_reqs value
of a current requirements.txt file.