Commit Graph

8 Commits

Author SHA1 Message Date
Greg Price 34f4c822cb 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 11:37:00 -08:00
Steve Howell 9391f7aa98 quick fix: Turn off git lint for Travis builds.
We may be having problems with git lint, so this is a quick
fix to hopefully get builds working again.
2017-12-27 18:20:18 -05:00
Tim Abbott b087886d1c 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-29 15:42:01 -07:00
Robert Hönig 3f01907d3b travis: Distribute linting over frontend and backend suites. 2017-08-27 13:51:06 -07:00
Greg Price 360c27dedd 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 15:31:32 -07:00
Joshua Pan fdb244fd3b node tests: Add support for enforcing 100% test coverage.
Fixes #5178.
2017-06-07 22:13:02 -07:00
Eklavya Sharma e86539649c Use tools/travis/activate-venv in test suites. 2016-07-19 14:15:35 -07:00
Tim Abbott 6eb670097c 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-11-01 18:11:39 -08:00