872e8c1d7b
In this commit we are fixing a kinda serious un-noticed bug with the way run_db_migrations worked for test db. Basically run_db_migrations runs new migrations on db (dev or test). When we talk about the dev platform this process is straight forward. We have a single DB zulip which was once created and now has some data. Introduction of new migration causes a schema change or does something else but bottom line being we just migrate the zulip DB and stuff works fine. Now coming to zulip test db (zulip_test) situation is a bit complex in comparision to dev db. Basically this is because we make use of what we call zulip_test_template to make test fixture restoration after tests run fast. Now before we introduced the performance optimisation of just doing migrations when possible, introduction of a migration would ideally result in provisioning do a full rebuild of the test database. When that used to happen sequence of events used to be something like this: * Create a zulip_test db from zulip_test_base template (An absolute basic schema holding) * Migrate and populate the zulip_test db. * Create/Re-create zulip_test_template from the latest zulip_test. Now after we introduced just do migrations instead of full db rebuild when possible, what used to happen was that zulip_test db got successfully migrated but when test suites would run they would try to create zulip_test from zulip_test_template (so that individual tests don't affect each other on db level). This is where the problem resides; zulip_test_template wasn't migrated and we just scrapped zulip_test and re-created it using zulip_test_template as a template and hence zulip_test will not hold the latest schema. This is what we fix in this commit.
Zulip overview
Zulip is a powerful, open source group chat application that combines the immediacy of real-time chat with the productivity benefits of threaded conversations. Zulip is used by open source projects, Fortune 500 companies, large standards bodies, and others who need a real-time chat system that allows users to easily process hundreds or thousands of messages a day. With over 300 contributors merging over 500 commits a month, Zulip is also the largest and fastest growing open source group chat project.
Getting started
Click on the appropriate link below. If nothing seems to apply, join us on the Zulip community server and tell us what's up!
You might be interested in:
-
Contributing code. Check out our guide for new contributors to get started. Zulip prides itself on maintaining a clean and well-tested codebase, and a stock of hundreds of beginner-friendly issues.
-
Contributing non-code. Report an issue, translate Zulip into your language, write for the Zulip blog, or give us feedback. We would love to hear from you, even if you're just trying the product out.
-
Supporting Zulip. Advocate for your organization to use Zulip, write a review in the mobile app stores, or upvote Zulip on product comparison sites.
-
Checking Zulip out. The best way to see Zulip in action is to drop by the Zulip community server. We also recommend reading Zulip for open source, Zulip for companies, or Zulip for working groups and part time communities.
-
Running a Zulip server. Setting up a server takes just a couple of minutes. Zulip runs on Ubuntu 18.04 Bionic, Ubuntu 16.04 Xenial, Ubuntu 14.04 Trusty, and Debian 9 Stretch. The installation process is documented here. Commercial support is available; see https://zulipchat.com/plans for details.
-
Using Zulip without setting up a server. https://zulipchat.com offers free and commercial hosting.
-
Applying for a Zulip internship. Zulip runs internship programs with Outreachy, Google Summer of Code, and the MIT Externship program. Zulip also participates in Google Code-In. More information is available here.
You may also be interested in reading our blog or following us on twitter. Zulip is distributed under the Apache 2.0 license.