zulip/tools/travis/backend

#!/bin/bash

source tools/travis/activate-venv

set -e
set -x

./tools/lint-all
./tools/test-backend --coverage --no-verbose-coverage
./tools/test-management
./tools/test-migrations
./tools/test-run-dev
./tools/test-documentation
# Some test suites disabled in CI for being flaky
#./tools/test-queue-worker-reload
Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work. 2015-10-15 01:47:42 +02:00			`#!/bin/bash`
Use tools/travis/activate-venv in test suites. 2016-07-18 23:22:10 +02:00
			`source tools/travis/activate-venv`

Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work. 2015-10-15 01:47:42 +02:00			`set -e`
			`set -x`
Use tools/travis/activate-venv in test suites. 2016-07-18 23:22:10 +02:00
Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work. 2015-10-15 01:47:42 +02:00			`./tools/lint-all`
travis: Remove verbose coverage report from end of build output. 2016-06-16 00:05:07 +02:00			`./tools/test-backend --coverage --no-verbose-coverage`
Add new test for management commands running with --help. This test caught a few bugs where refactoring had made management commands fail (and would have caught a few more recent ones). Ideally we'd replace this with a more advanced test that actually tests that the management command do something useful, but it's a start. 2015-11-10 06:56:08 +01:00			`./tools/test-management`
travis: Test whether migrations are consistent with models. This should automatically catch mistakes where someone updates the database models but forgets to generate migrations afterwards. 2016-01-10 05:15:19 +01:00			`./tools/test-migrations`
Add run-dev.py test to Travis CI test suites. Fixes #919 2016-06-07 11:48:48 +02:00			`./tools/test-run-dev`
docs-test: Check only http 404 error for external links. - Raise exception only for http 404 error rensponse, for other http error codes used logging to notify devs about wrong links. 2016-10-29 19:54:17 +02:00			`./tools/test-documentation`
travis: Disable test-documentation temporarily. 2016-10-28 20:27:16 +02:00			`# Some test suites disabled in CI for being flaky`
travis: re-disable test-queue-worker-reload. It seems to still fail sometimes in Travis CI. 2016-08-11 01:42:55 +02:00			`#./tools/test-queue-worker-reload`
docs-test: Check only http 404 error for external links. - Raise exception only for http 404 error rensponse, for other http error codes used logging to notify devs about wrong links. 2016-10-29 19:54:17 +02:00