Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/tools/ci/frontend

24 lines
646 B
Plaintext
Raw Normal View History

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
tools: Rename tools/travis directory to tools/ci.
2018-12-10 08:05:16 +01:00
source tools/ci/activate-venv
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
set -e
set -x
Use tools/travis/activate-venv in test suites.
2016-07-18 23:22:10 +02:00
ci: Cut out commented-out versions of tools/lint calls. This may or may not be temporary, but either way, the other code is there in source control, and the "why" of disabling gitlint is the helpful bit for a comment.
2018-02-01 20:37:00 +01:00
./tools/lint --frontend --no-gitlint # gitlint disabled because flaky
travis: Move i18n and capitalization linters to frontend. Since these usually result from changes to HTML templates and other frontend-side things, it seems better to group them with the frontend. [Tweaked by gnprice in whitespace and comments.]
2017-08-27 22:42:54 +02:00
# Run the node tests first, since they're fast and deterministic
node tests: Add support for enforcing 100% test coverage. Fixes #5178.
2017-06-07 04:24:39 +02:00
./tools/test-js-with-node --coverage
travis: Move i18n and capitalization linters to frontend. Since these usually result from changes to HTML templates and other frontend-side things, it seems better to group them with the frontend. [Tweaked by gnprice in whitespace and comments.]
2017-08-27 22:42:54 +02:00
# Check capitalization of strings
./manage.py makemessages --locale en
PYTHONWARNINGS=ignore ./tools/check-capitalization --no-generate
PYTHONWARNINGS=ignore ./tools/check-frontend-i18n --no-generate
# Run the slower Casper tests last
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/test-js-with-casper
tests: Bring all the top-level test scripts into alignment on what to test. Notably, this adds our checks on translated message strings to `tools/test-all`, so that they don't cause surprise failures in CI after a branch is pushed. (Alternately they could have gone in `tools/lint` to accomplish the same goal, but `makemessages` which they depend on is quite slow -- on my machine it takes 7s, compared to 10s for all of `tools/lint`.)
2017-07-25 04:46:15 +02:00
# NB: Everything here should be in `tools/test-all`. If there's a
# reason not to run it there, it should be there as a comment
# explaining why.