Because git < 1.8.1 ignores lines with trailing slashes and
1.8.1.1 - 1.8.1.6 ignore lines without!
(imported from commit 8139a742f4a52ccb1bce4e06fb24c9626fdb01f2)
update-prod-static needs DEBUG=False. This also replaces our
local_settings.py before generating anything included in the tarball.
(imported from commit 890cd9d1a44acfd2c20e1662e0c68132c633d1b3)
We still need it in integrations, because those don't require Python
2.7, but we don't need it in any of our code that runs on internal
servers.
(imported from commit 3c340567f1a372dcb4206c6af9a6e5e18005b1b8)
The corporate "app" is not a full-fledged Django app, but it has
a urls.py and a templates directory. This commit creates the app
and moves the jobs pages into it. Localserver deployments will
not see any of the corporate code.
(imported from commit 35889c3cf92329258c30741fdfa564769a4fac1a)
The main use-case here is for ensuring that we don't deploy to master
while doing demos.
(imported from commit d3c8ba502052b352291548200032f39e0743b774)
Run the following commands as root before deploying this branch:
# /root/zulip/tools/migrate-server-config
# rm /etc/zulip/machinetype /etc/zulip/server /etc/zulip/local /etc/humbug-machinetype /etc/humbug-server /etc/humbug-local
(imported from commit aa7dcc50d2f4792ce33834f14761e76512fca252)
This moves the list of removed files from .gitattributes to
tools/build-local-server-tarball because static/ and tools/ are
necessary for update-prod-static, and it seemed best to keep the
entire list in one place.
(imported from commit 2a447cbde29e90d776da43bb333650a40d4d363c)
update-deployment has been replaced by upgrade-zulip for local server
instances, since it won't be running off a git repository, and
update-prod-static won't be needed since we plan on shipping minified
javascript.
When we deploy this, the deployment will fail, and then we'll need to
update the git checkout from which post-receive runs on git.zulip.net.
(imported from commit 86aaedbab09c60ae86ac1d0ae492d0d1bc45569f)
I switched narrow.by_subject and narrow.by_recipient to use the all_msg_list
instead of current_msg_list, since we wanted to be able to narrow to messages
specifically not in the current_msg_list. However, in searches which revealed
old messages outside the range of all_msg_list (which only has a single contiguous range),
this broke narrowing.
Let's use msg_metadata_cache instead.
(imported from commit 427f717484b4ae83d9bb4cc6e51ce17177d037fe)
Looking at the historical data, fewer than 50% of active users have
completed the checklist, which means that it is just persistent
clutter. We also have other better ways of encouraging people to send
traffic and get the apps now.
This commit removes both the frontend UI and backend work but leaves
the db row for now for the historical data.
(imported from commit e8f5780be37bbc75f794fb118e4dd41d8811f2bf)
We need to maintain this by labeling the files that we don't want to
ship with our local server tarballs in the .gitattributes file.
(imported from commit e29f38c477a4cdfd80fbb8e4e95c611b34f3b212)
Check that settings.html has at least balanced tags, and
automate the checking of those tags.
(imported from commit 35e9be269caa211803d64f2b54cb0287e13707b3)
We need to do a puppet apply immediately after deploying this, or our
rabbitmq consumer state files will become stale.
(imported from commit 18696a5a8b1ff431425d1f71c208acc9bf0694f2)
This requires no changes in production, but is tagged as manual to
remind developers that they need to edit and run the tools/migrate-db
script to fix up their local database instances.
(imported from commit fbf764fb61592ef994d6d2ad56edad65ff01f14b)
This commit must be simultaneously deployed on both staging and
prod0. It also requires completely taking down the app.
To deploy these changes, do:
* check out this commit at /root/zulip on postgres0, postgres1, staging, and prod0
* stop the process_fts_updates job on postgres0 and postgres1
* stop the app on staging and prod0
* do a puppet apply on postgres0, postgres1, staging, and prod0
* move the new client certificates into place on staging and app
* move the new server certificates into place on postgres0 and postgres1
* reload the database config on postgres0 and postgres1 (this might
actually require a restart)
* run tools/migrate-db on postgres0 as root
* do a deploy through this commit on staging and prod0
* start the process_fts_updates job on postgres0 and postgres1
* do a puppet apply on nagios
(imported from commit 819bdd14326c1425e2d3041a491a8ca3b9716506)
Kevin Mehall
Tim Abbott
Zev Benjamin
Luke Faraone
Steve Howell
Leo Franchi
acrefoot
Jessica McKellar