mirror of https://github.com/zulip/zulip.git
docs: Fix more capitalization issues.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg
Tim Abbott
parent
a7d1fd9ffb
commit
72d6ff3c3b
|
|
@ -1,10 +1,10 @@
|
|||
<!-- What's this PR for? (Just a link to an issue is fine.) -->
|
||||
|
||||
|
||||
**Testing Plan:** <!-- How have you tested? -->
|
||||
**Testing plan:** <!-- How have you tested? -->
|
||||
|
||||
|
||||
**GIFs or Screenshots:** <!-- If a UI change. See:
|
||||
**GIFs or screenshots:** <!-- If a UI change. See:
|
||||
https://zulip.readthedocs.io/en/latest/tutorials/screenshot-and-gif-software.html
|
||||
-->
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
name: Cancel Previous Runs
|
||||
name: Cancel previous runs
|
||||
on: [push, pull_request]
|
||||
|
||||
defaults:
|
||||
|
|
@ -7,7 +7,7 @@ defaults:
|
|||
|
||||
jobs:
|
||||
cancel:
|
||||
name: Cancel Previous Runs
|
||||
name: Cancel previous runs
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 3
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
name: "Code Scanning"
|
||||
name: "Code scanning"
|
||||
|
||||
on: [push, pull_request]
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
name: Zulip Production Suite
|
||||
name: Zulip production suite
|
||||
|
||||
on:
|
||||
push:
|
||||
|
|
@ -30,7 +30,7 @@ defaults:
|
|||
|
||||
jobs:
|
||||
production_build:
|
||||
name: Bionic Production Build
|
||||
name: Bionic production build
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# This docker image was created by a generated Dockerfile at:
|
||||
|
|
@ -104,12 +104,12 @@ jobs:
|
|||
matrix:
|
||||
include:
|
||||
- docker_image: mepriyank/actions:bionic
|
||||
name: Bionic Production Install
|
||||
name: Bionic production install
|
||||
is_bionic: true
|
||||
os: bionic
|
||||
|
||||
- docker_image: mepriyank/actions:focal
|
||||
name: Focal Production Install
|
||||
name: Focal production install
|
||||
is_focal: true
|
||||
os: focal
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ jobs:
|
|||
# GitHub Actions sets HOME to /github/home which causes
|
||||
# problem later in provison and frontend test that runs
|
||||
# tools/setup/postgres-init-dev-db because of the .pgpass
|
||||
# location. Postgresql (psql) expects .pgpass to be at
|
||||
# location. PostgreSQL (psql) expects .pgpass to be at
|
||||
# /home/github/.pgpass and setting home to `/home/github/`
|
||||
# ensures it written there because we write it to ~/.pgpass.
|
||||
HOME: /home/github/
|
||||
|
|
@ -142,7 +142,7 @@ jobs:
|
|||
# see https://community.codecov.io/t/http-400-while-uploading-to-s3-with-python-codecov-from-travis/1428/7
|
||||
pip install codecov && codecov || echo "Error in uploading coverage reports to codecov.io."
|
||||
|
||||
- name: Store puppeteer artifacts
|
||||
- name: Store Puppeteer artifacts
|
||||
if: ${{ matrix.include_frontend_tests }}
|
||||
uses: actions/upload-artifact@v2
|
||||
with:
|
||||
|
|
@ -153,6 +153,6 @@ jobs:
|
|||
if: ${{ matrix.is_focal }}
|
||||
run: mispipe "tools/ci/setup-backend" ts
|
||||
# TODO: We need to port the notify_failure step from CircleCI
|
||||
# config, however, it might be the case that GitHub Notifications
|
||||
# make this unnesscary. More details on settings to configure it:
|
||||
# config, however, it might be the case that GitHub notifications
|
||||
# make this unnecessary. More details on settings to configure it:
|
||||
# https://help.github.com/en/github/managing-subscriptions-and-notifications-on-github/configuring-notifications#github-actions-notification-options
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
# the on-disk data in volumes. So the base image can not currently be upgraded
|
||||
# without users needing a manual pgdump and restore.
|
||||
|
||||
# Install hunspell, zulip stop words, and run zulip database
|
||||
# Install hunspell, Zulip stop words, and run Zulip database
|
||||
# init.
|
||||
FROM groonga/pgroonga:latest-alpine-10-slim
|
||||
RUN apk add -U --no-cache hunspell-en
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ over 500 contributors merging over 500 commits a month, Zulip is also the
|
|||
largest and fastest growing open source group chat project.
|
||||
|
||||
[](https://circleci.com/gh/zulip/zulip/tree/master)
|
||||
[](https://codecov.io/gh/zulip/zulip/branch/master)
|
||||
[](https://codecov.io/gh/zulip/zulip/branch/master)
|
||||
[][mypy-coverage]
|
||||
[](https://github.com/prettier/prettier)
|
||||
[](https://github.com/zulip/zulip/releases/latest)
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
# Security Policy
|
||||
# Security policy
|
||||
|
||||
Security announcements are sent to zulip-announce@googlegroups.com,
|
||||
so you should subscribe if you are running Zulip in production.
|
||||
|
||||
## Reporting a Vulnerability
|
||||
## Reporting a vulnerability
|
||||
|
||||
We love responsible reports of (potential) security issues in Zulip,
|
||||
whether in the latest release or our development branch.
|
||||
|
|
@ -18,7 +18,7 @@ Our [security
|
|||
model](https://zulip.readthedocs.io/en/latest/production/security-model.html)
|
||||
document may be a helpful resource.
|
||||
|
||||
## Supported Versions
|
||||
## Supported versions
|
||||
|
||||
Zulip provides security support for the latest major release, in the
|
||||
form of minor security/maintenance releases.
|
||||
|
|
|
|||
|
|
@ -598,7 +598,7 @@ def get_count_stats(realm: Optional[Realm]=None) -> Dict[str, CountStat]:
|
|||
## CountStat declarations ##
|
||||
|
||||
count_stats_ = [
|
||||
# Messages Sent stats
|
||||
# Messages sent stats
|
||||
# Stats that count the number of messages sent in various ways.
|
||||
# These are also the set of stats that read from the Message table.
|
||||
|
||||
|
|
@ -617,7 +617,7 @@ def get_count_stats(realm: Optional[Realm]=None) -> Dict[str, CountStat]:
|
|||
sql_data_collector(StreamCount, count_message_by_stream_query(realm),
|
||||
(UserProfile, 'is_bot')), CountStat.DAY),
|
||||
|
||||
# Number of Users stats
|
||||
# Number of users stats
|
||||
# Stats that count the number of active users in the UserProfile.is_active sense.
|
||||
|
||||
# 'active_users_audit:is_bot:day' is the canonical record of which users were
|
||||
|
|
@ -658,7 +658,7 @@ def get_count_stats(realm: Optional[Realm]=None) -> Dict[str, CountStat]:
|
|||
LoggingCountStat('messages_read::hour', UserCount, CountStat.HOUR),
|
||||
LoggingCountStat('messages_read_interactions::hour', UserCount, CountStat.HOUR),
|
||||
|
||||
# User Activity stats
|
||||
# User activity stats
|
||||
# Stats that measure user activity in the UserActivityInterval sense.
|
||||
|
||||
CountStat('1day_actives::day',
|
||||
|
|
|
|||
|
|
@ -437,7 +437,7 @@ class TestSupportEndpoint(ZulipTestCase):
|
|||
zulip_realm = get_realm("zulip")
|
||||
self.assert_in_success_response([f'<input type="hidden" name="realm_id" value="{zulip_realm.id}"',
|
||||
'Zulip Dev</h3>',
|
||||
'<option value="1" selected>Self Hosted</option>',
|
||||
'<option value="1" selected>Self hosted</option>',
|
||||
'<option value="2" >Limited</option>',
|
||||
'input type="number" name="discount" value="None"',
|
||||
'<option value="active" selected>Active</option>',
|
||||
|
|
@ -449,7 +449,7 @@ class TestSupportEndpoint(ZulipTestCase):
|
|||
lear_realm = get_realm("lear")
|
||||
self.assert_in_success_response([f'<input type="hidden" name="realm_id" value="{lear_realm.id}"',
|
||||
'Lear & Co.</h3>',
|
||||
'<option value="1" selected>Self Hosted</option>',
|
||||
'<option value="1" selected>Self hosted</option>',
|
||||
'<option value="2" >Limited</option>',
|
||||
'input type="number" name="discount" value="None"',
|
||||
'<option value="active" selected>Active</option>',
|
||||
|
|
|
|||
|
|
@ -172,14 +172,14 @@ def get_chart_data_for_remote_realm(
|
|||
|
||||
@require_server_admin
|
||||
def stats_for_installation(request: HttpRequest) -> HttpResponse:
|
||||
return render_stats(request, '/installation', 'Installation', True)
|
||||
return render_stats(request, '/installation', 'installation', True)
|
||||
|
||||
@require_server_admin
|
||||
def stats_for_remote_installation(request: HttpRequest, remote_server_id: int) -> HttpResponse:
|
||||
assert settings.ZILENCER_ENABLED
|
||||
server = RemoteZulipServer.objects.get(id=remote_server_id)
|
||||
return render_stats(request, f'/remote/{server.id}/installation',
|
||||
f'remote Installation {server.hostname}', True, True)
|
||||
f'remote installation {server.hostname}', True, True)
|
||||
|
||||
@require_server_admin_api
|
||||
@has_request_variables
|
||||
|
|
@ -787,9 +787,9 @@ def user_activity_intervals() -> Tuple[mark_safe, Dict[str, float]]:
|
|||
|
||||
realm_minutes[string_id] = realm_duration.total_seconds() / 60
|
||||
|
||||
output += f"\nTotal Duration: {total_duration}\n"
|
||||
output += f"\nTotal Duration in minutes: {total_duration.total_seconds() / 60.}\n"
|
||||
output += f"Total Duration amortized to a month: {total_duration.total_seconds() * 30. / 60.}"
|
||||
output += f"\nTotal duration: {total_duration}\n"
|
||||
output += f"\nTotal duration in minutes: {total_duration.total_seconds() / 60.}\n"
|
||||
output += f"Total duration amortized to a month: {total_duration.total_seconds() * 30. / 60.}"
|
||||
content = mark_safe('<pre>' + output + '</pre>')
|
||||
return content, realm_minutes
|
||||
|
||||
|
|
@ -1328,7 +1328,7 @@ def raw_user_activity_table(records: List[QuerySet]) -> str:
|
|||
]
|
||||
|
||||
rows = list(map(row, records))
|
||||
title = 'Raw Data'
|
||||
title = 'Raw data'
|
||||
return make_table(title, cols, rows)
|
||||
|
||||
def get_user_activity_summary(records: List[QuerySet]) -> Dict[str, Dict[str, Any]]:
|
||||
|
|
@ -1473,7 +1473,7 @@ def user_activity_summary_table(user_summary: Dict[str, Dict[str, Any]]) -> str:
|
|||
'count',
|
||||
]
|
||||
|
||||
title = 'User Activity'
|
||||
title = 'User activity'
|
||||
return make_table(title, cols, rows)
|
||||
|
||||
def realm_user_summary_table(all_records: List[QuerySet],
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ method][install-vagrant].
|
|||
|
||||
If you have a very slow network connection, however, you may want to
|
||||
avoid using Vagrant (which involves downloading an Ubuntu virtual
|
||||
machine or Linux Container) and either
|
||||
machine or Linux container) and either
|
||||
[install directly][install-direct] (recommended), or use
|
||||
[the manual install process][install-generic] instead. These options
|
||||
only support Linux.
|
||||
|
|
@ -71,7 +71,7 @@ need to.
|
|||
Once you've installed the Zulip development environment, you'll want
|
||||
to read these documents to learn how to use it:
|
||||
|
||||
* [Using the Development Environment][using-dev-env]
|
||||
* [Using the development environment][using-dev-env]
|
||||
* [Testing][testing] (and [Configuring CI][ci])
|
||||
|
||||
And if you've set up the Zulip development environment on a remote
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ Now your workspace should look similar this:
|
|||
Next, read the following to learn more about developing for Zulip:
|
||||
|
||||
* [Git & GitHub Guide][rtd-git-guide]
|
||||
* [Using the Development Environment][rtd-using-dev-env]
|
||||
* [Using the development environment][rtd-using-dev-env]
|
||||
* [Testing][rtd-testing]
|
||||
|
||||
[install-direct]: ../development/setup-advanced.html#installing-directly-on-ubuntu-debian-centos-or-fedora
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ Once you've confirmed you can connect to your remote server, take a look at:
|
|||
|
||||
Next, read the following to learn more about developing for Zulip:
|
||||
|
||||
* [Using the Development Environment](../development/using.md)
|
||||
* [Using the development environment](../development/using.md)
|
||||
* [Testing](../testing/testing.md)
|
||||
|
||||
[github-join]: https://github.com/join
|
||||
|
|
|
|||
|
|
@ -2,19 +2,19 @@
|
|||
|
||||
Contents:
|
||||
|
||||
* [Installing directly on Ubuntu, Debian, Centos, or Fedora](#installing-directly-on-ubuntu-debian-centos-or-fedora)
|
||||
* [Installing directly on Ubuntu, Debian, CentOS, or Fedora](#installing-directly-on-ubuntu-debian-centos-or-fedora)
|
||||
* [Installing directly on Windows 10](#installing-directly-on-windows-10-experimental)
|
||||
* [Installing manually on other Linux/UNIX](#installing-manually-on-unix)
|
||||
* [Installing directly on cloud9](#installing-on-cloud9)
|
||||
|
||||
## Installing directly on Ubuntu, Debian, Centos, or Fedora
|
||||
## Installing directly on Ubuntu, Debian, CentOS, or Fedora
|
||||
|
||||
If you'd like to install a Zulip development environment on a computer
|
||||
that's running one of:
|
||||
|
||||
* Ubuntu 20.04 Focal, 18.04 Bionic
|
||||
* Debian 10 Buster
|
||||
* Centos 7 (beta)
|
||||
* CentOS 7 (beta)
|
||||
* Fedora 29 (beta)
|
||||
* RHEL 7 (beta)
|
||||
|
||||
|
|
@ -279,14 +279,14 @@ proxy in the environment as follows:
|
|||
yarn config set https-proxy http://proxy_host:port
|
||||
```
|
||||
|
||||
## Installing on cloud9
|
||||
## Installing on Cloud9
|
||||
|
||||
AWS Cloud9 is a cloud-based integrated development environment (IDE)
|
||||
that lets you write, run, and debug your code with just a browser. It
|
||||
includes a code editor, debugger, and terminal.
|
||||
|
||||
This section documents how to set up the Zulip development environment
|
||||
in a cloud9 workspace. If you don't have an existing cloud9 account,
|
||||
in a Cloud9 workspace. If you don't have an existing Cloud9 account,
|
||||
you can sign up [here](https://aws.amazon.com/cloud9/).
|
||||
|
||||
* Create a Workspace, and select the blank template.
|
||||
|
|
@ -295,10 +295,10 @@ you can sign up [here](https://aws.amazon.com/cloud9/).
|
|||
Free Tier).
|
||||
* Clone the zulip repo: `git clone --config pull.rebase
|
||||
https://github.com/<your-username>/zulip.git`
|
||||
* Restart rabbitmq-server since its broken on cloud9: `sudo service
|
||||
* Restart rabbitmq-server since its broken on Cloud9: `sudo service
|
||||
rabbitmq-server restart`.
|
||||
* And run provision `cd zulip && ./tools/provision`, once this is done.
|
||||
* Activate the zulip virtual environment by `source
|
||||
* Activate the Zulip virtual environment by `source
|
||||
/srv/zulip-py3-venv/bin/activate` or by opening a new terminal.
|
||||
|
||||
#### Install zulip-cloud9
|
||||
|
|
@ -321,7 +321,7 @@ you need to start a new terminal.
|
|||
|
||||
Your development server would be running at
|
||||
`https://<workspace-name>-<username>.c9users.io` on port 8080. You
|
||||
dont need to add `:8080` to your url, since the cloud9 proxy should
|
||||
dont need to add `:8080` to your URL, since the Cloud9 proxy should
|
||||
automatically forward the connection. You might want to visit
|
||||
[zulip-cloud9 repo](https://github.com/cPhost/zulip-cloud9) and it's
|
||||
[wiki](https://github.com/cPhost/zulip-cloud9/wiki) for more info on
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ to GitHub working on your machine.
|
|||
|
||||
Follow our [Git guide][set-up-git] in order to install Git, set up a
|
||||
GitHub account, create an SSH key to access code on GitHub
|
||||
efficiently, etc. Be sure to create an ssh key and add it to your
|
||||
efficiently, etc. Be sure to create an SSH key and add it to your
|
||||
GitHub account using
|
||||
[these instructions](https://help.github.com/en/articles/generating-an-ssh-key).
|
||||
|
||||
|
|
@ -83,8 +83,8 @@ Jump to:
|
|||
1. Install [Vagrant][vagrant-dl] (latest).
|
||||
2. Install [VirtualBox][vbox-dl] (latest).
|
||||
|
||||
(For a non-free option, but better performance, you can also use [VMWare
|
||||
Fusion][vmware-fusion-dl] with the [VMWare Fusion Vagrant
|
||||
(For a non-free option, but better performance, you can also use [VMware
|
||||
Fusion][vmware-fusion-dl] with the [VMware Fusion Vagrant
|
||||
plugin][vagrant-vmware-fusion-dl] or [Parallels Desktop][parallels-desktop-dl] as
|
||||
a provider for Vagrant.)
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ git remote add -f upstream https://github.com/zulip/zulip.git
|
|||
|
||||
This will create a 'zulip' directory and download the Zulip code into it.
|
||||
|
||||
Don't forget to replace YOURUSERNAME with your git username. You will see
|
||||
Don't forget to replace YOURUSERNAME with your Git username. You will see
|
||||
something like:
|
||||
|
||||
```
|
||||
|
|
@ -534,7 +534,7 @@ $ ./tools/run-dev.py
|
|||
Next, read the following to learn more about developing for Zulip:
|
||||
|
||||
* [Git & GitHub Guide][rtd-git-guide]
|
||||
* [Using the Development Environment][rtd-using-dev-env]
|
||||
* [Using the development environment][rtd-using-dev-env]
|
||||
* [Testing][rtd-testing] (and [Configuring CI][ci] to
|
||||
run the full test suite against any branches you push to your fork,
|
||||
which can help you optimize your development workflow).
|
||||
|
|
@ -803,7 +803,7 @@ that failed. Once you've resolved the problem, you can rerun
|
|||
`tools/provision` to proceed; the provisioning system is designed
|
||||
to recover well from failures.
|
||||
|
||||
The zulip provisioning system is generally highly reliable; the most common
|
||||
The Zulip provisioning system is generally highly reliable; the most common
|
||||
cause of issues here is a poor network connection (or one where you need a
|
||||
proxy to access the Internet and haven't [configured the development
|
||||
environment to use it](#specifying-a-proxy).
|
||||
|
|
@ -985,7 +985,7 @@ connect to your development server.
|
|||
### Customizing CPU and RAM allocation
|
||||
|
||||
When running Vagrant using a VM-based provider such as VirtualBox or
|
||||
VMWare Fusion, CPU and RAM resources must be explicitly allocated to
|
||||
VMware Fusion, CPU and RAM resources must be explicitly allocated to
|
||||
the guest system (with Docker and other container-based Vagrant
|
||||
providers, explicit allocation is unnecessary and the settings
|
||||
described here are ignored).
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Zulip servers. These docs are written in
|
|||
[Commonmark Markdown](https://commonmark.org/) with a small bit of rST.
|
||||
We've chosen Markdown because it is
|
||||
[easy to write](https://commonmark.org/help/). The source for Zulip's
|
||||
developer documentation is at `docs/` in the Zulip git repository, and
|
||||
developer documentation is at `docs/` in the Zulip Git repository, and
|
||||
they are served in production at
|
||||
[zulip.readthedocs.io](https://zulip.readthedocs.io/en/latest/).
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ payload verification. Note that this test does not check for broken
|
|||
links (those are checked by `test-help-documentation`).
|
||||
|
||||
* `tools/test-help-documentation` checks `/help/`, `/api/`,
|
||||
`/integrations/`, and the Core website ("portico") documentation for
|
||||
`/integrations/`, and the core website ("portico") documentation for
|
||||
broken links. Note that the "portico" documentation check has a
|
||||
manually maintained whitelist of pages, so if you add a new page to
|
||||
this site, you will need to edit `PorticoDocumentationSpider` to add it.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ The feature articles serve a few different purposes:
|
|||
* Feature discovery, for someone browsing the `/help` page, and looking at
|
||||
the set of titles.
|
||||
* Public documentation of our featureset, for someone googling "can zulip do .."
|
||||
* Canned responses to support questions; if someone emails a zulip admin
|
||||
* Canned responses to support questions; if someone emails a Zulip admin
|
||||
asking "how do I change my name", they can reply with a link to the doc.
|
||||
* Feature explanations for new Zulip users and admins, especially for
|
||||
organization settings.
|
||||
|
|
@ -239,9 +239,9 @@ languages in API docs, etc. To create a tab switcher, write:
|
|||
|
||||
{start_tabs}
|
||||
{tab|desktop-web}
|
||||
# First Tab's content
|
||||
# First tab's content
|
||||
{tab|ios}
|
||||
# Second Tab's content
|
||||
# Second tab's content
|
||||
{tab|android}
|
||||
# Third tab's content
|
||||
{end_tabs}
|
||||
|
|
|
|||
|
|
@ -51,8 +51,8 @@ Finally, install the [Zulip developer environment][zulip-rtd-dev-overview], and
|
|||
***
|
||||
|
||||
The following sections will help you be awesome with Zulip and Git/GitHub in a
|
||||
rebased-based workflow. Read through it if you're new to git, to a rebase-based
|
||||
git workflow, or if you'd like a git refresher.
|
||||
rebased-based workflow. Read through it if you're new to Git, to a rebase-based
|
||||
Git workflow, or if you'd like a Git refresher.
|
||||
|
||||
[gitbook-rebase]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
|
||||
[github-rebase-pr]: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ administrator][git-bash-admin] at all times.**
|
|||
You'll also need a GitHub account, which you can sign up for
|
||||
[here][github-join].
|
||||
|
||||
We highly recommend you create an ssh key if you don't already have
|
||||
We highly recommend you create an SSH key if you don't already have
|
||||
one and [add it to your GitHub account][github-help-add-ssh-key]. If
|
||||
you don't, you'll have to type your GitHub username and password every
|
||||
time you interact with GitHub, which is usually several times a day.
|
||||
|
|
@ -44,7 +44,7 @@ If you don't already have one installed, here are some suggestions:
|
|||
- Windows: [SourceTree][gitgui-sourcetree]
|
||||
|
||||
If you like working on the command line, but want better visualization and
|
||||
navigation of your git repo, try [Tig][tig], a cross-platform ncurses-based
|
||||
navigation of your Git repo, try [Tig][tig], a cross-platform ncurses-based
|
||||
text-mode interface to Git.
|
||||
|
||||
And, if none of the above are to your liking, try [one of these][gitbook-guis].
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Important Git terms
|
||||
|
||||
When you install Git, it adds a manual entry for `gitglossary`. You can view
|
||||
this glossary by running `man gitglossary`. Below we've included the git terms
|
||||
this glossary by running `man gitglossary`. Below we've included the Git terms
|
||||
you'll encounter most often along with their definitions from *gitglossary*.
|
||||
|
||||
## branch
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Working copies
|
||||
|
||||
When you work on Zulip code, there are three working copies
|
||||
of the Zulip git repo that you are generally concerned with:
|
||||
of the Zulip Git repo that you are generally concerned with:
|
||||
|
||||
- local copy: This lives on your laptop or your remote dev instance.
|
||||
- forked copy: This lives on GitHub, and it's tied to your account.
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ from outside.
|
|||
and the production build process (`tools/build-release-tarball`)
|
||||
compiles, minifies, and installs the static assets into the
|
||||
`prod-static/` tree form. In development, files are served directly
|
||||
from `/static/` in the git repository.
|
||||
from `/static/` in the Git repository.
|
||||
- Requests to `/json/events` and `/api/v1/events`, i.e. the
|
||||
real-time push system, are sent to the Tornado server.
|
||||
- Requests to all other paths are sent to the Django app running via
|
||||
|
|
@ -184,25 +184,25 @@ persistence:
|
|||
# Zulip-specific configuration: disable saving to disk.
|
||||
save ""
|
||||
|
||||
People often wonder if we could replace memcached with redis (or
|
||||
replace RabbitMQ with redis, with some loss of functionality).
|
||||
People often wonder if we could replace memcached with Redis (or
|
||||
replace RabbitMQ with Redis, with some loss of functionality).
|
||||
|
||||
The answer is likely yes, but it wouldn't improve Zulip.
|
||||
Operationally, our current setup is likely easier to develop and run
|
||||
in production than a pure redis system would be. Meanwhile, the
|
||||
perceived benefit for using redis is usually to reduce memory
|
||||
in production than a pure Redis system would be. Meanwhile, the
|
||||
perceived benefit for using Redis is usually to reduce memory
|
||||
consumption by running fewer services, and no such benefit would
|
||||
materialize:
|
||||
|
||||
* Our cache uses significant memory, but that memory usage would be
|
||||
essentially the same with redis as it is with memcached.
|
||||
essentially the same with Redis as it is with memcached.
|
||||
* All of these services have low minimum memory requirements, and in
|
||||
fact our applications for redis and RabbitMQ do not use significant
|
||||
fact our applications for Redis and RabbitMQ do not use significant
|
||||
memory even at scale.
|
||||
* We would likely need to run multiple redis services (with different
|
||||
* We would likely need to run multiple Redis services (with different
|
||||
configurations) in order to ensure the pure LRU use case (memcached)
|
||||
doesn't push out data that we want to persist until expiry
|
||||
(redis-based rate limiting) or until consumed (RabbitMQ-based
|
||||
(Redis-based rate limiting) or until consumed (RabbitMQ-based
|
||||
queuing of deferred work).
|
||||
|
||||
### RabbitMQ
|
||||
|
|
@ -237,12 +237,12 @@ with the operating system.
|
|||
In production, Postgres is installed with a default configuration. The
|
||||
directory that would contain configuration files
|
||||
(`puppet/zulip/files/postgresql`) has only a utility script and a custom
|
||||
list of stopwords used by a Postgresql extension.
|
||||
list of stopwords used by a PostgreSQL extension.
|
||||
|
||||
In a development environment, configuration of that postgresql
|
||||
In a development environment, configuration of that PostgreSQL
|
||||
extension is handled by `tools/postgres-init-dev-db` (invoked by
|
||||
`tools/provision`). That file also manages setting up the
|
||||
development postgresql user.
|
||||
development PostgreSQL user.
|
||||
|
||||
`tools/provision` also invokes `tools/rebuild-dev-database`
|
||||
to create the actual database with its schema.
|
||||
|
|
@ -289,9 +289,9 @@ self-explanatory names.
|
|||
|
||||
* **ellipsis**: A small vertical three dot icon (technically called
|
||||
as ellipsis-v), present in sidebars as a menu icon.
|
||||
It offers contextual options for Global Filters(All messages
|
||||
and Starred messages), Stream Filters and Topics in left
|
||||
sidebar and User in right sidebar. To avoid visual clutter
|
||||
It offers contextual options for global filters (All messages
|
||||
and Starred messages), stream filters and topics in left
|
||||
sidebar and users in right sidebar. To avoid visual clutter
|
||||
ellipsis only appears in the web UI upon hover.
|
||||
|
||||
* **huddle**: What the codebase calls a "group private message".
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ in bursts.
|
|||
data will fascilitate future features showing a log of activity by
|
||||
a given user or changes to an organization's settings.
|
||||
- Added support for using Sentry for processing backend exceptions.
|
||||
- Added documentation for using `wal-g` for continuous postgres backups.
|
||||
- Added documentation for using `wal-g` for continuous Postgres backups.
|
||||
- Added loading spinners for message editing widgets.
|
||||
- Added live update of compose placeholder text when recipients change.
|
||||
- The Zoom integration is now stable (no longer beta).
|
||||
|
|
@ -50,7 +50,7 @@ in bursts.
|
|||
- Fixed screenreader accessibility of many components, including
|
||||
the compose box, message editing, popovers, and many more.
|
||||
- Improved formatting of GitLab integration.
|
||||
- Improved positioning logic for inline Youtube previews.
|
||||
- Improved positioning logic for inline YouTube previews.
|
||||
- Upgraded our ancient forked version of bootstrap, on a path towards
|
||||
removing the last forked dependencies from the codebase.
|
||||
- Updated webapp codebase to use many modern ES6 patterns.
|
||||
|
|
@ -124,7 +124,7 @@ in bursts.
|
|||
- The Zulip server now sets badge counts for the iOS mobile app.
|
||||
- Quote-and-reply now generates a handy link to the quoted message.
|
||||
- Upgraded Django from 1.11.x to the latest LTS series, 2.2.x.
|
||||
- Added integrations for ErrBit, Grafana, Thinkst Canary, and AlertManager.
|
||||
- Added integrations for ErrBit, Grafana, Thinkst Canary, and Alertmanager.
|
||||
- Extended API documentation to have detailed data on most responses,
|
||||
validated against the API's actual implementation and against all
|
||||
tests in our extensive automated test suite.
|
||||
|
|
@ -132,7 +132,7 @@ in bursts.
|
|||
global/default policy and policies for specific streams.
|
||||
- Added a new incoming webhook API that accepts messages in the format
|
||||
used by Slack's incoming webhooks API.
|
||||
- Introduced the Zulip API Feature Level, a concept that will greatly
|
||||
- Introduced the Zulip API feature level, a concept that will greatly
|
||||
simplify the implementation of mobile, terminal, and desktop clients
|
||||
that need to talk to a wide range of supported Zulip server
|
||||
versions, as well as the [Zulip API
|
||||
|
|
@ -162,22 +162,22 @@ in bursts.
|
|||
accounts affected by this bug, so we expect the vast majority of
|
||||
installations will have none.
|
||||
- This release switches Zulip to install Postgres 12 from the upstream
|
||||
postgres repository by default, rather than using the default
|
||||
Postgres repository by default, rather than using the default
|
||||
Postgres version included with the operating system. Existing Zulip
|
||||
installations will continue to work with Postgres 10; this detail is
|
||||
configured in `/etc/zulip/zulip.conf`. We have no concrete plans to
|
||||
start requiring Postgres 12, though we do expect it to improve
|
||||
performance. Installations that would like to upgrade can follow
|
||||
[our new postgres upgrade guide][postgres-upgrade].
|
||||
[our new Postgres upgrade guide][postgres-upgrade].
|
||||
- The format of the `JWT_AUTH_KEYS` setting has changed to include an
|
||||
[algorithms](https://pyjwt.readthedocs.io/en/latest/algorithms.html)
|
||||
list: `{"subdomain": "key"}` becomes `{"subdomain": {"key": "key",
|
||||
"algorithms": ["HS256"]}}`.
|
||||
- Added a new Organization Owner permission above the previous
|
||||
Organization Administrator. All existing organization
|
||||
- Added a new organization owner permission above the previous
|
||||
organization administrator. All existing organization
|
||||
administrators are automatically converted into organization owners.
|
||||
Certain sensitive administrative settings are now only
|
||||
editable by Organization Owners.
|
||||
editable by organization owners.
|
||||
- The changelog now has a section that makes it easy to find the
|
||||
Upgrade notes for all releases one is upgrading across.
|
||||
|
||||
|
|
@ -322,7 +322,7 @@ in bursts.
|
|||
### 2.1.7 -- 2020-06-25
|
||||
|
||||
- CVE-2020-15070: Fix privilege escalation vulnerability with custom
|
||||
profile fields and direct write access to Zulip's postgres database.
|
||||
profile fields and direct write access to Zulip's Postgres database.
|
||||
- Changed default memcached authentication username to zulip@localhost,
|
||||
fixing authentication problems when servers change their hostname.
|
||||
|
||||
|
|
@ -366,7 +366,7 @@ details.
|
|||
|
||||
- Fixed a regression in 2.1.3 that impacted creating the very first
|
||||
organization via our data import tools.
|
||||
- Remove the old `tsearch_extras` postgres extension, which was causing
|
||||
- Remove the old `tsearch_extras` Postgres extension, which was causing
|
||||
an exception restoring backups on fresh Zulip servers that had been
|
||||
generated on systems that had been upgraded from older Zulip releases.
|
||||
- Removed fetching GitHub contributor data from static asset build
|
||||
|
|
@ -398,7 +398,7 @@ details.
|
|||
- Fixed copy-to-clipboard button for outgoing webhook bots.
|
||||
- Fixed logging spam from soft_deactivation cron job.
|
||||
- Fixed email integration handling of emails with nested MIME structure.
|
||||
- Fixed unicode bugs in incoming email integration.
|
||||
- Fixed Unicode bugs in incoming email integration.
|
||||
- Fixed error handling for Slack data import.
|
||||
- Fixed incoming webhook support for AWX 9.x.y.
|
||||
- Fixed a couple missing translation tags.
|
||||
|
|
@ -413,8 +413,8 @@ details.
|
|||
- Corrected fix for CVE-2019-19775 (the original fix was affected by
|
||||
an unfixed security bug in Python's urllib, CVE-2015-2104).
|
||||
- Migrated data for handling replies to missed-message emails from
|
||||
semi-persistent redis to the fully persistent database.
|
||||
- Added authentication for redis and memcached even in configurations
|
||||
semi-persistent Redis to the fully persistent database.
|
||||
- Added authentication for Redis and memcached even in configurations
|
||||
where these are running on localhost, for add hardening against
|
||||
attacks from malicious processes running on the Zulip server.
|
||||
- Improved logging for misconfigurations of LDAP authentication.
|
||||
|
|
@ -444,7 +444,7 @@ details.
|
|||
- Added support for Debian buster. Removed support for EOL Ubuntu Trusty.
|
||||
- Added support for SAML authentication.
|
||||
- Removed our dependency on `tsearch_extras`, making it possible to
|
||||
run a production Zulip server against any postgres database
|
||||
run a production Zulip server against any Postgres database
|
||||
(including those where one cannot install extensions, like Amazon RDS).
|
||||
- Significantly improved the email->Zulip gateway, and added [nice
|
||||
setup documentation](../production/email-gateway.md). It now
|
||||
|
|
@ -488,7 +488,7 @@ configure this feature entirely in the UI. However, servers that had
|
|||
previously [enabled previews of linked
|
||||
websites](https://zulip.com/help/allow-image-link-previews) will
|
||||
lose the setting and need to re-enable it.
|
||||
- We rewrote the Google Authentication backend to use the
|
||||
- We rewrote the Google authentication backend to use the
|
||||
`python-social-auth` system we use for other third-party
|
||||
authentication systems. For this release, the old variable names
|
||||
still work, but users should update the following setting names in
|
||||
|
|
@ -644,7 +644,7 @@ lose the setting and need to re-enable it.
|
|||
joined that stream.
|
||||
- Fixed several subtle real-time sync issues with "stream settings".
|
||||
- Fixed a few subtle Markdown processor bugs involving emoji.
|
||||
- Fixed several issues where Linkifiers validation was overly restrictive.
|
||||
- Fixed several issues where linkifiers validation was overly restrictive.
|
||||
- Fixed several rare/minor UI consistency issues in the left sidebar.
|
||||
- Fixed issues involving saving a message edit before file upload completes.
|
||||
- Fixed issues with pasting images into the compose box from Safari.
|
||||
|
|
@ -700,7 +700,7 @@ lose the setting and need to re-enable it.
|
|||
- Fixed a table layout bug in "deactivated users" settings.
|
||||
- Fixed an exception when administrators edited bot users when custom
|
||||
profile fields were configured in the organization.
|
||||
- Fixed a bug enabling the PGRoonga search backend with older postgres.
|
||||
- Fixed a bug enabling the PGRoonga search backend with older Postgres.
|
||||
- Fixed getting personal API key when passwords are disabled.
|
||||
|
||||
### 2.0.3 -- 2019-04-23
|
||||
|
|
@ -714,11 +714,11 @@ lose the setting and need to re-enable it.
|
|||
such a version by default, but one can install it manually).
|
||||
- Fixed `manage.py query_ldap` test tool (broken in 2.0.2).
|
||||
- Fixed several bugs in new backup and restore tools.
|
||||
- Fixed minor bugs with Youtube previews.
|
||||
- Fixed minor bugs with YouTube previews.
|
||||
|
||||
### 2.0.2 -- 2019-03-15
|
||||
|
||||
- Fixed a regression in the puppet configuration for S3 upload backend
|
||||
- Fixed a regression in the Puppet configuration for S3 upload backend
|
||||
introduced in 2.0.1.
|
||||
- Fixed a too-fast fade for "Saved" in organization settings.
|
||||
- Fixed a white flash when loading a browser in night mode.
|
||||
|
|
@ -821,7 +821,7 @@ and is enabled by default in that case. To disable it, set
|
|||
- Improved accessibility of emoji rendering in messages bodies.
|
||||
- Eliminated UI lag when using "Quote and reply".
|
||||
- Expanded production documentation for more unusual deployment options.
|
||||
- Expanded set of characters allowed in custom Linkifiers.
|
||||
- Expanded set of characters allowed in custom linkifiers.
|
||||
- Optimized development provisioning; now takes 2s in the no-op case.
|
||||
- Zulip's Help Center now has nicely generated open graph tags.
|
||||
- Fixed missing API authentication headers for mobile file access.
|
||||
|
|
@ -842,11 +842,11 @@ and is enabled by default in that case. To disable it, set
|
|||
### 1.9.2 -- 2019-01-29
|
||||
|
||||
This release migrates Zulip off a deprecated Google+ API (necessary
|
||||
for Google Authentication to continue working past March 7), and
|
||||
for Google authentication to continue working past March 7), and
|
||||
contains a few bug fixes for the installer and Slack import. It has
|
||||
minimal changes for existing servers not using Google authentication.
|
||||
|
||||
- Updated the Google Auth integration to stop using a deprecated and
|
||||
- Updated the Google auth integration to stop using a deprecated and
|
||||
soon-to-be-removed Google+ authentication API.
|
||||
- Improved installer error messages for common configuration problems.
|
||||
- Fixed several bugs in Slack, Gitter, and HipChat import tools.
|
||||
|
|
@ -976,7 +976,7 @@ Zulip installations; it has minimal changes for existing servers.
|
|||
- Improved Zulip's layout for windows with a width around 1024px.
|
||||
- Improved Zulip's generic error handling behavior for webhooks.
|
||||
- Improved keyboard navigation of settings and popovers.
|
||||
- Renamed "Realm Filters" to "Linkifiers", at least in the UI.
|
||||
- Renamed "realm filters" to "linkifiers", at least in the UI.
|
||||
- Converted several layered-checkbox settings to clearer dropdowns.
|
||||
- Cleaned up some legacy APIs still using email addresses.
|
||||
- Made arrow-key navigation work within right and left sidebar search.
|
||||
|
|
@ -1079,7 +1079,7 @@ Zulip installations; it has minimal changes for existing servers.
|
|||
public streams, even though from before a user subscribed.
|
||||
- Added a menu item to mark all messages as read.
|
||||
- Fixed image upload file pickers offering non-image files.
|
||||
- Fixed some subtle bugs with full-text search and unicode.
|
||||
- Fixed some subtle bugs with full-text search and Unicode.
|
||||
- Fixed bugs in the "edit history" HTML rendering process.
|
||||
- Fixed popovers being closed when new messages come in.
|
||||
- Fixed unexpected code blocks when using the email mirror.
|
||||
|
|
@ -1413,7 +1413,7 @@ running a version from before 1.7 should upgrade directly to 1.7.1.
|
|||
- Simplified the settings for configuring senders for our emails.
|
||||
- Emoji can now be typed with spaces, e.g. entering "robot face" in
|
||||
the typeahead as well as "robot_face".
|
||||
- Improved title and alt text for unicode emoji.
|
||||
- Improved title and alt text for Unicode emoji.
|
||||
- Added development tools to make iterating on emails and error pages easy.
|
||||
- Added backend support for multi-use invite links (no UI for creating yet).
|
||||
- Added a central debugging log for attempts to send outgoing emails.
|
||||
|
|
@ -1486,7 +1486,7 @@ Zulip apps.
|
|||
* Added an icon to distinguish bot users as message senders.
|
||||
* Added a command-line Slack importer tool using the API.
|
||||
* Added new announcement notifications on stream creation.
|
||||
* Added support for some newer unicode emoji code points.
|
||||
* Added support for some newer Unicode emoji code points.
|
||||
* Added support for users deleting realm emoji they themselves uploaded.
|
||||
* Added support for organization administrators deleting messages.
|
||||
* Extended data available to mobile apps to cover the entire API.
|
||||
|
|
@ -1523,7 +1523,7 @@ Zulip apps.
|
|||
* Fixed numerous bugs with the message editing widget.
|
||||
* Fixed missing logging / rate limiting on browser endpoints.
|
||||
* Fixed regressions in Zulip's browser state preservation on reload logic.
|
||||
* Fixed support for unicode characters in the email mirror system.
|
||||
* Fixed support for Unicode characters in the email mirror system.
|
||||
* Fixed load spikes when email mirror is receiving a lot of traffic.
|
||||
* Fixed the ugly grey flicker when scrolling fast on Macs.
|
||||
* Fixed previews of GitHub image URLs.
|
||||
|
|
@ -1597,7 +1597,7 @@ Zulip apps.
|
|||
- Added a webhook integration for GitHub, replacing the deprecated
|
||||
github-services hook.
|
||||
- Normalized the message formatting for all the Zulip Git integrations.
|
||||
- Added support for VMWare Fusion Vagrant provider for faster OSX
|
||||
- Added support for VMware Fusion Vagrant provider for faster OSX
|
||||
development.
|
||||
- Added a shields.io style badge for joining a Zulip server.
|
||||
- Added admin setting for which email domains can join a realm.
|
||||
|
|
@ -1630,7 +1630,7 @@ Zulip apps.
|
|||
- Added several new linters (eslint, pep8) and cleaned the codebase.
|
||||
- Optimized the speed of the Zulip upgrade process, especially with Git.
|
||||
- Have peer_add events send user_id, not email.
|
||||
- Fixed problems with rabbitmq when installing Zulip.
|
||||
- Fixed problems with RabbitMQ when installing Zulip.
|
||||
- Fixed JavaScript not being gzip-compressed properly.
|
||||
- Fixed a major performance bug in the Tornado service.
|
||||
- Fixed a frontend performance bug creating streams in very large realms.
|
||||
|
|
@ -1702,8 +1702,8 @@ Zulip apps.
|
|||
- Added management command for creating realms through web UI.
|
||||
- Added management command to send password reset emails.
|
||||
- Added endpoint for mobile apps to query available auth backends.
|
||||
- Added LetsEncrypt documentation for getting SSL certificates.
|
||||
- Added nice rendering of unicode emoji.
|
||||
- Added Let's Encrypt documentation for getting SSL certificates.
|
||||
- Added nice rendering of Unicode emoji.
|
||||
- Added support for pinning streams to the top of the left sidebar.
|
||||
- Added search box for filtering user list when creating a new stream.
|
||||
- Added realm setting to disable message editing.
|
||||
|
|
@ -1714,10 +1714,10 @@ Zulip apps.
|
|||
easy to add additional social authentication methods).
|
||||
- Added TERMS_OF_SERVICE setting using Markdown formatting to configure
|
||||
the terms of service for a Zulip server.
|
||||
- Added numerous hooks to puppet modules to enable more configurations.
|
||||
- Moved several useful puppet components into the main puppet
|
||||
manifests (setting a redis password, etc.).
|
||||
- Added automatic configuration of postgres/memcached settings based
|
||||
- Added numerous hooks to Puppet modules to enable more configurations.
|
||||
- Moved several useful Puppet components into the main Puppet
|
||||
manifests (setting a Redis password, etc.).
|
||||
- Added automatic configuration of Postgres/memcached settings based
|
||||
on the server's available RAM.
|
||||
- Added scripts/upgrade-zulip-from-git for upgrading Zulip from a Git repo.
|
||||
- Added preliminary support for Python 3. All of Zulip's test suites now
|
||||
|
|
@ -1732,7 +1732,7 @@ Zulip apps.
|
|||
- Improved missed message emails to better support directly replying.
|
||||
- Increased backend test coverage of Python code to 85.5%.
|
||||
- Increased mypy static type coverage of Python code to 95%. Also
|
||||
fixed many string annotations to properly handle unicode.
|
||||
fixed many string annotations to properly handle Unicode.
|
||||
- Fixed major i18n-related frontend performance regression on
|
||||
/#subscriptions page. Saves several seconds of load time with 1k
|
||||
streams.
|
||||
|
|
@ -1749,7 +1749,7 @@ Zulip apps.
|
|||
- Fixed EPMD restart being attempted on every puppet apply.
|
||||
- Fixed message cache filling; should improve perf after server restart.
|
||||
- Fixed caching race condition when changing user objects.
|
||||
- Fixed buggy puppet configuration for supervisord restarts.
|
||||
- Fixed buggy Puppet configuration for supervisord restarts.
|
||||
- Fixed some error handling race conditions when editing messages.
|
||||
- Fixed fastcgi_params to protect against the httpoxy attack.
|
||||
- Fixed bug preventing users with mit.edu emails from registering accounts.
|
||||
|
|
@ -1757,7 +1757,7 @@ Zulip apps.
|
|||
- Fixed APNS push notification support (had been broken by Apple changing
|
||||
the APNS API).
|
||||
- Fixed some logic bugs in how attachments are tracked.
|
||||
- Fixed unnecessarily resource-intensive rabbitmq cron checks.
|
||||
- Fixed unnecessarily resource-intensive RabbitMQ cron checks.
|
||||
- Fixed old deployment directories leaking indefinitely.
|
||||
- Fixed need to manually add localhost in ALLOWED_HOSTS.
|
||||
- Fixed display positioning for the color picker on subscriptions page.
|
||||
|
|
@ -1817,7 +1817,7 @@ Zulip apps.
|
|||
- Fixed erroneous WWW-Authenticate headers with expired sessions.
|
||||
- Changed "coworkers" to "users" in the Zulip UI.
|
||||
- Changed add_default_stream REST API to correctly use PUT rather than PATCH.
|
||||
- Updated the Zulip emoji set (the Android Emoji) to a modern version.
|
||||
- Updated the Zulip emoji set (the Android emoji) to a modern version.
|
||||
- Made numerous small improvements to the Zulip development experience.
|
||||
- Migrated backend templates to the faster Jinja2 templating system.
|
||||
- Migrated development environment setup scripts to tools/setup/.
|
||||
|
|
@ -1844,7 +1844,7 @@ Zulip apps.
|
|||
- Added ability for realm administrators to manage custom emoji.
|
||||
- Added guide to writing new integrations.
|
||||
- Enabled camo image proxy to fix mixed-content warnings for http images.
|
||||
- Refactored the Zulip puppet modules to be more modular.
|
||||
- Refactored the Zulip Puppet modules to be more modular.
|
||||
- Refactored the Tornado event system, fixing old memory leaks.
|
||||
- Removed many old-style /json API endpoints
|
||||
- Implemented running queue processors multithreaded in development,
|
||||
|
|
@ -1864,7 +1864,7 @@ Zulip apps.
|
|||
- Added new integration for Travis CI.
|
||||
- Added settings option to control maximum file upload size.
|
||||
- Added support for running Zulip development environment in Docker.
|
||||
- Added easy configuration support for a remote postgres database.
|
||||
- Added easy configuration support for a remote Postgres database.
|
||||
- Added extensive documentation on scalability, backups, and security.
|
||||
- Recent private message threads are now displayed expanded similar to
|
||||
the pre-existing recent topics feature.
|
||||
|
|
@ -1886,7 +1886,7 @@ Zulip apps.
|
|||
- Fixed buggy #! lines in upgrade scripts.
|
||||
|
||||
### 1.3.8 - 2015-11-15
|
||||
- Added options to the Python api for working with untrusted server certificates.
|
||||
- Added options to the Python API for working with untrusted server certificates.
|
||||
- Added a lot of documentation on the development environment and testing.
|
||||
- Added partial support for translating the Zulip UI.
|
||||
- Migrated installing Node dependencies to use npm.
|
||||
|
|
@ -1913,7 +1913,7 @@ Zulip apps.
|
|||
This section links to the upgrade notes from past releases, so you can
|
||||
easily read them all when upgrading across multiple releases.
|
||||
|
||||
* [Draft Upgrade notes for 4.0](#upgrade-notes-for-4-0)
|
||||
* [Draft upgrade notes for 4.0](#upgrade-notes-for-4-0)
|
||||
* [Upgrade notes for 3.0](#upgrade-notes-for-3-0)
|
||||
* [Upgrade notes for 2.1.5](#upgrade-notes-for-2-1-5)
|
||||
* [Upgrade notes for 2.1.0](#upgrade-notes-for-2-1-0)
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ Django context (i.e. with database access).
|
|||
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
### Production puppet configuration
|
||||
### Production Puppet configuration
|
||||
|
||||
This is used to deploy essentially all configuration in production.
|
||||
|
||||
|
|
|
|||
|
|
@ -242,7 +242,7 @@ the areas mentioned above are not your main strength.
|
|||
|
||||
As a data point, in Summer 2017, we had 4 students working on the
|
||||
React Native mobile app (1 focused primarily on visual design), 1 on
|
||||
the Electron Desktop app, 2 on bots/integrations, 1 on webapp visual
|
||||
the Electron desktop app, 2 on bots/integrations, 1 on webapp visual
|
||||
design, 2 on our development tooling and automated testing
|
||||
infrastructure, and the remaining 4 on various other parts of the
|
||||
backend and core webapp.
|
||||
|
|
@ -348,7 +348,7 @@ CSS](https://github.com/zulip/zulip/).
|
|||
(likely part 1) is
|
||||
[here](../subsystems/custom-apps.md).
|
||||
**Skills recommended**: Python and JavaScript/CSS, plus devops
|
||||
skills (Linux deployment, Docker, puppet etc.) are all useful here.
|
||||
skills (Linux deployment, Docker, Puppet etc.) are all useful here.
|
||||
Experience writing tools using various popular APIs is helpful for
|
||||
being able to make good choices. Experts: Steve Howell.
|
||||
|
||||
|
|
@ -454,7 +454,7 @@ Expert: Tommy Ip, Tim Abbott.
|
|||
adding [mypy](../testing/mypy.md) stubs
|
||||
for Django in mypy to make our type checking more powerful. Read
|
||||
[our mypy blog post](https://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/)
|
||||
for details on how mypy works and is integrated into zulip. This
|
||||
for details on how mypy works and is integrated into Zulip. This
|
||||
specific project is ideal for a strong contributor interested in
|
||||
type systems.
|
||||
|
||||
|
|
|
|||
|
|
@ -56,8 +56,8 @@ file and you'll find inline documentation in comments for how to
|
|||
configure it.
|
||||
|
||||
Since some of these services require some configuration on the node
|
||||
itself (e.g. installing our `postgres` extensions), we have designed
|
||||
the puppet configuration that Zulip uses for installing and upgrading
|
||||
itself (e.g. installing our Postgres extensions), we have designed
|
||||
the Puppet configuration that Zulip uses for installing and upgrading
|
||||
configuration to be completely modular.
|
||||
|
||||
For example, you can install a Zulip rabbitmq server on a machine, you
|
||||
|
|
@ -74,7 +74,7 @@ of includes in
|
|||
though it's also possible to subclass some of the lower-level
|
||||
manifests defined in that directory if you want to customize. A good
|
||||
example of doing this is in the
|
||||
[zulip_ops puppet configuration][zulipchat-puppet] that we use as part
|
||||
[zulip_ops Puppet configuration][zulipchat-puppet] that we use as part
|
||||
of managing chat.zulip.org and zulip.com.
|
||||
|
||||
### Using Zulip with Amazon RDS as the database
|
||||
|
|
@ -117,7 +117,7 @@ This complication will be removed in a future version.
|
|||
|
||||
#### Step 2: Create the Postgres database
|
||||
|
||||
Access an administrative `psql` shell on your postgres database, and
|
||||
Access an administrative `psql` shell on your Postgres database, and
|
||||
run the commands in `scripts/setup/create-db.sql` to:
|
||||
|
||||
* Create a database called `zulip`.
|
||||
|
|
@ -126,7 +126,7 @@ run the commands in `scripts/setup/create-db.sql` to:
|
|||
`zulip` in the `zulip` database. You might have to grant `create`
|
||||
privileges first for the `zulip` user to do this.
|
||||
|
||||
Depending on how authentication works for your postgres installation,
|
||||
Depending on how authentication works for your Postgres installation,
|
||||
you may also need to set a password for the Zulip user, generate a
|
||||
client certificate, or similar; consult the documentation for your
|
||||
database provider for the available options.
|
||||
|
|
@ -134,11 +134,11 @@ database provider for the available options.
|
|||
#### Step 3: Configure Zulip to use the Postgres database
|
||||
|
||||
In `/etc/zulip/settings.py` on your Zulip server, configure the
|
||||
following settings with details for how to connect to your postgres
|
||||
following settings with details for how to connect to your Postgres
|
||||
server. Your database provider should provide these details.
|
||||
|
||||
* `REMOTE_POSTGRES_HOST`: Name or IP address of the postgres server.
|
||||
* `REMOTE_POSTGRES_PORT`: Port on the postgres server.
|
||||
* `REMOTE_POSTGRES_HOST`: Name or IP address of the Postgres server.
|
||||
* `REMOTE_POSTGRES_PORT`: Port on the Postgres server.
|
||||
* `REMOTE_POSTGRES_SSLMODE`: SSL Mode used to connect to the server.
|
||||
|
||||
If you're using password authentication, you should specify the
|
||||
|
|
@ -152,7 +152,7 @@ postgres_password = abcd1234
|
|||
Now complete the installation by running the following commands.
|
||||
|
||||
```
|
||||
# Ask Zulip installer to initialize the postgres database.
|
||||
# Ask Zulip installer to initialize the Postgres database.
|
||||
su zulip -c '/home/zulip/deployments/current/scripts/setup/initialize-database'
|
||||
|
||||
# And then generate a realm creation link:
|
||||
|
|
@ -233,7 +233,7 @@ For `nginx` configuration, there's two things you need to set up:
|
|||
`/etc/nginx/sites-available`) for the Zulip app. You can look at
|
||||
our [nginx reverse proxy configuration][nginx-loadbalancer] to see
|
||||
an example of how to do this properly (the various include files are
|
||||
available via the `zulip::nginx` puppet module). Or modify this
|
||||
available via the `zulip::nginx` Puppet module). Or modify this
|
||||
example:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ records in DNS.
|
|||
|
||||
## Local delivery setup
|
||||
|
||||
Zulip's puppet configuration provides everything needed to run this
|
||||
Zulip's Puppet configuration provides everything needed to run this
|
||||
integration; you just need to enable and configure it as follows.
|
||||
|
||||
The main decision you need to make is what email domain you want to
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ can run them manually before starting the upgrade:
|
|||
/home/zulip/deployments/current`
|
||||
2. Run `./manage.py dbshell`. This will open a shell connected to the
|
||||
Postgres database.
|
||||
3. In the postgres shell, run the following commands:
|
||||
3. In the Postgres shell, run the following commands:
|
||||
|
||||
CREATE INDEX CONCURRENTLY
|
||||
zerver_usermessage_is_private_message_id
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ service (or back):
|
|||
* Backups must be restored on a server running the same Zulip
|
||||
version (most precisely, one where `manage.py showmigrations` has
|
||||
the same output).
|
||||
* Backups must be restored on a server running the same `postgres`
|
||||
* Backups must be restored on a server running the same Postgres
|
||||
version.
|
||||
* Backups aren't useful for migrating organizations between
|
||||
self-hosting and Zulip Cloud (which may require renumbering all
|
||||
|
|
@ -20,7 +20,7 @@ service (or back):
|
|||
|
||||
We highly recommend this tool in situations where it is applicable,
|
||||
because it is highly optimized and highly stable, since the hard
|
||||
work is done by the built-in backup feature of `postgres`. We also
|
||||
work is done by the built-in backup feature of Postgres. We also
|
||||
document [backup details](#backup-details) for users managing
|
||||
backups manually.
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ service (or back):
|
|||
Like the backup tool, logical data exports must be imported on a
|
||||
Zulip server running the same version. However, logical data
|
||||
exports can be imported on Zulip servers running a different
|
||||
`postgres` version or hosting a different set of Zulip
|
||||
Postgres version or hosting a different set of Zulip
|
||||
organizations. We recommend this tool in cases where the backup
|
||||
tool isn't applicable, including situations where an easily
|
||||
machine-parsable export format is desired.
|
||||
|
|
@ -47,7 +47,7 @@ service (or back):
|
|||
inexpensively preserve public stream conversations when
|
||||
decommissioning a Zulip organization.
|
||||
|
||||
* It's possible to set up [postgres streaming
|
||||
* It's possible to set up [Postgres streaming
|
||||
replication](#postgres-streaming-replication) and the [S3 file
|
||||
upload
|
||||
backend](../production/upload-backends.html#s3-backend-configuration)
|
||||
|
|
@ -69,7 +69,7 @@ The backup tool provides the following options:
|
|||
to (default: write to a file in `/tmp`). On success, the
|
||||
console output will show the path to the output tarball.
|
||||
- `--skip-db`: Skip backup of the database. Useful if you're using a
|
||||
remote postgres host with its own backup system and just need to
|
||||
remote Postgres host with its own backup system and just need to
|
||||
backup non-database state.
|
||||
- `--skip-uploads`: If `LOCAL_UPLOADS_DIR` is set, user-uploaded files
|
||||
in that directory will be ignored.
|
||||
|
|
@ -154,19 +154,19 @@ emails to send). You can check whether these queues are empty using
|
|||
#### Backup details
|
||||
|
||||
This section is primarily for users managing backups themselves
|
||||
(E.g. if they're using a remote postgres database with an existing
|
||||
(E.g. if they're using a remote Postgres database with an existing
|
||||
backup strategy), and also serves as documentation for what is
|
||||
included in the backups generated by Zulip's standard tools. The
|
||||
data includes:
|
||||
|
||||
* The postgres database. You can back it up like any postgres
|
||||
* The Postgres database. You can back it up like any Postgres
|
||||
database. We have some example tooling for doing that incrementally
|
||||
into S3 using [wal-g](https://github.com/wal-g/wal-g) in
|
||||
`puppet/zulip/manifests/postgres_backups.pp`.
|
||||
In short, this requires:
|
||||
- Zulip 1.4 or newer release.
|
||||
- An Amazon S3 bucket for storing the backups.
|
||||
- `/etc/zulip/zulip-secrets.conf` on the postgres server like this:
|
||||
- `/etc/zulip/zulip-secrets.conf` on the Postgres server like this:
|
||||
```
|
||||
[secrets]
|
||||
s3_backups_key = # aws public key
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ sudo wget -O /etc/nginx/nginx.conf.zulip \
|
|||
sudo meld /etc/nginx/nginx.conf /etc/nginx/nginx.conf.zulip # be sure to merge to the right
|
||||
```
|
||||
|
||||
After the zulip installation completes, then you can overwrite (or
|
||||
After the Zulip installation completes, then you can overwrite (or
|
||||
merge) your new nginx.conf with the installed one:
|
||||
|
||||
```shell
|
||||
|
|
@ -41,13 +41,13 @@ $ sudo meld /etc/nginx/nginx.conf.zulip /etc/nginx/nginx.conf # be sure to merg
|
|||
$ sudo service nginx restart
|
||||
```
|
||||
|
||||
Zulip's puppet configuration will change the ownership of
|
||||
Zulip's Puppet configuration will change the ownership of
|
||||
`/var/log/nginx` so that the `zulip` user can access it. Depending on
|
||||
your configuration, this may or may not cause problems.
|
||||
|
||||
### Puppet
|
||||
|
||||
If you have a puppet server running on your server, you will get an
|
||||
If you have a Puppet server running on your server, you will get an
|
||||
error message about not being able to connect to the client during the
|
||||
install process:
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ install process:
|
|||
puppet-agent[29873]: Could not request certificate: Failed to open TCP connection to puppet:8140
|
||||
```
|
||||
|
||||
So you'll need to shutdown any puppet servers.
|
||||
So you'll need to shutdown any Puppet servers.
|
||||
|
||||
```shell
|
||||
$ sudo service puppet-agent stop
|
||||
|
|
@ -75,7 +75,7 @@ If you have an existing PostgreSQL database, note that Zulip will use
|
|||
the default `main` as its database name; make sure you're not using
|
||||
that.
|
||||
|
||||
### Memcached, redis, and rabbitmq
|
||||
### Memcached, Redis, and RabbitMQ
|
||||
|
||||
Zulip will, by default, configure these services for its use. The
|
||||
configuration we use is pretty basic, but if you're using them for
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ The vast majority of Zulip servers host just a single organization (or
|
|||
documents what's involved in hosting multiple Zulip organizations on a
|
||||
single server.
|
||||
|
||||
Throughout this article, we'll assume you're working on a zulip server
|
||||
Throughout this article, we'll assume you're working on a Zulip server
|
||||
with hostname `zulip.example.com`. You may also find the more
|
||||
[technically focused article on realms](../subsystems/realms.md) to be useful
|
||||
reading.
|
||||
|
|
@ -33,7 +33,7 @@ things:
|
|||
file. That setting is the default in 1.7 and later.
|
||||
* Make sure you have SSL certificates for all of the subdomains you're
|
||||
going to use. If you're using
|
||||
[our LetsEncrypt instructions](ssl-certificates.md), it's easy to
|
||||
[our Let's Encrypt instructions](ssl-certificates.md), it's easy to
|
||||
just specify multiple subdomains in your certificate request.
|
||||
* If necessary, modify your `nginx` configuration to use your new
|
||||
certificates.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Previous versions of Zulip used whatever version of Postgres was
|
|||
included with the base operating system (E.g. Postgres 12 on Ubuntu
|
||||
Focal, 10 on Ubuntu Bionic, and 9.6 on Ubuntu Xenial). We recommend
|
||||
that installations currently using older Postgres releases [upgrade to
|
||||
Postgres 12][upgrade-postgres], as may drop support for older postgres
|
||||
Postgres 12][upgrade-postgres], as may drop support for older Postgres
|
||||
in a future release.
|
||||
|
||||
[upgrade-postgres]: ../production/upgrade-or-modify.html#upgrading-postgresql
|
||||
|
|
@ -16,7 +16,7 @@ in a future release.
|
|||
#### Remote Postgres database
|
||||
|
||||
This is a bit annoying to set up, but you can configure Zulip to use a
|
||||
dedicated postgres server by setting the `REMOTE_POSTGRES_HOST`
|
||||
dedicated Postgres server by setting the `REMOTE_POSTGRES_HOST`
|
||||
variable in /etc/zulip/settings.py, and configuring Postgres
|
||||
certificate authentication (see
|
||||
http://www.postgresql.org/docs/9.1/static/ssl-tcp.html and
|
||||
|
|
@ -25,11 +25,11 @@ documentation on how to set this up and deploy the certificates) to
|
|||
make the DATABASES configuration in `zproject/computed_settings.py`
|
||||
work (or override that configuration).
|
||||
|
||||
If you want to use a remote Postgresql database, you should configure
|
||||
If you want to use a remote PostgreSQL database, you should configure
|
||||
the information about the connection with the server. You need a user
|
||||
called "zulip" in your database server. You can configure these
|
||||
options in `/etc/zulip/settings.py` (the below descriptions are from the
|
||||
Postgresql documentation):
|
||||
PostgreSQL documentation):
|
||||
|
||||
* `REMOTE_POSTGRES_HOST`: Name or IP address of the remote host
|
||||
* `REMOTE_POSTGRES_SSLMODE`: SSL Mode used to connect to the server,
|
||||
|
|
@ -64,15 +64,15 @@ sudo update-rc.d postgresql disable
|
|||
```
|
||||
|
||||
In future versions of this feature, we'd like to implement and
|
||||
document how to the remote postgres database server itself
|
||||
document how to the remote Postgres database server itself
|
||||
automatically by using the Zulip install script with a different set
|
||||
of puppet manifests than the all-in-one feature; if you're interested
|
||||
of Puppet manifests than the all-in-one feature; if you're interested
|
||||
in working on this, post to the Zulip development mailing list and we
|
||||
can give you some tips.
|
||||
|
||||
#### Debugging postgres database issues
|
||||
#### Debugging Postgres database issues
|
||||
|
||||
When debugging postgres issues, in addition to the standard `pg_top`
|
||||
When debugging Postgres issues, in addition to the standard `pg_top`
|
||||
tool, often it can be useful to use this query:
|
||||
|
||||
```
|
||||
|
|
@ -92,9 +92,9 @@ sending a Postgres process SIGKILL. Doing so will cause the database
|
|||
to kill all current connections, roll back any pending transactions,
|
||||
and enter recovery mode.
|
||||
|
||||
#### Stopping the Zulip postgres database
|
||||
#### Stopping the Zulip Postgres database
|
||||
|
||||
To start or stop postgres manually, use the pg_ctlcluster command:
|
||||
To start or stop Postgres manually, use the pg_ctlcluster command:
|
||||
|
||||
```
|
||||
pg_ctlcluster 9.1 [--force] main {start|stop|restart|reload}
|
||||
|
|
@ -120,7 +120,7 @@ Many database parameters can be adjusted while the database is
|
|||
running. Just modify /etc/postgresql/9.1/main/postgresql.conf and
|
||||
issue a reload. The logs will note the change.
|
||||
|
||||
#### Debugging issues starting postgres
|
||||
#### Debugging issues starting Postgres
|
||||
|
||||
pg_ctlcluster often doesn't give you any information on why the
|
||||
database failed to start. It may tell you to check the logs, but you
|
||||
|
|
@ -141,7 +141,7 @@ pg_ctlcluster does.
|
|||
|
||||
#### Postgres vacuuming alerts
|
||||
|
||||
The `autovac_freeze` postgres alert from `check_postgres` is
|
||||
The `autovac_freeze` Postgres alert from `check_postgres` is
|
||||
particularly important. This alert indicates that the age (in terms
|
||||
of number of transactions) of the oldest transaction id (XID) is
|
||||
getting close to the `autovacuum_freeze_max_age` setting. When the
|
||||
|
|
@ -154,4 +154,4 @@ database as a database superuser (`postgres`).
|
|||
|
||||
See
|
||||
http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
|
||||
for more details on postgres vacuuming.
|
||||
for more details on Postgres vacuuming.
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ For details on each of these requirements, see below.
|
|||
#### General
|
||||
|
||||
The installer expects Zulip to be the **only thing** running on the
|
||||
system; it will install system packages with `apt` (like nginx,
|
||||
postgresql, and redis) and configure them for its own use. We
|
||||
system; it will install system packages with `apt` (like Nginx,
|
||||
PostgreSQL, and Redis) and configure them for its own use. We
|
||||
strongly recommend using either a fresh machine instance in a cloud
|
||||
provider, a fresh VM, or a dedicated machine. If you decide to
|
||||
disregard our advice and use a server that hosts other services, we
|
||||
|
|
@ -50,7 +50,7 @@ https://help.ubuntu.com/community/Repositories/Ubuntu
|
|||
|
||||
#### Hardware specifications
|
||||
|
||||
* CPU and Memory: For installations with 100+ users you'll need a
|
||||
* CPU and memory: For installations with 100+ users you'll need a
|
||||
minimum of **2 CPUs** and **4GB RAM**. For installations with fewer
|
||||
users, 1 CPU and 2GB RAM is sufficient. We strongly recommend against
|
||||
installing with less than 2GB of RAM, as you will likely experience
|
||||
|
|
@ -149,7 +149,7 @@ most use cases, there's little scalability benefit to doing so. See
|
|||
installing Zulip with a dedicated database server.
|
||||
|
||||
* **Dedicated database**. For installations with hundreds of daily
|
||||
active users, we recommend using a [remote postgres
|
||||
active users, we recommend using a [remote Postgres
|
||||
database](postgres.md), but it's not required.
|
||||
|
||||
* **RAM:** We recommended more RAM for larger installations:
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ announcement).
|
|||
prevent CSRF attacks.
|
||||
|
||||
* The preferred way to log in to Zulip is using an SSO solution like
|
||||
Google Auth, LDAP, or similar, but Zulip also supports password
|
||||
Google auth, LDAP, or similar, but Zulip also supports password
|
||||
authentication. See
|
||||
[the authentication methods documentation](../production/authentication-methods.md)
|
||||
for details on Zulip's available authentication methods.
|
||||
|
|
@ -134,11 +134,11 @@ strength allowed is controlled by two settings in
|
|||
|
||||
## Users and bots
|
||||
|
||||
* There are several types of users in a Zulip organization: Organization
|
||||
Owners, Organization Administrators, Members (normal users), Guests,
|
||||
and Bots.
|
||||
* There are several types of users in a Zulip organization: organization
|
||||
owners, organization administrators, members (normal users), guests,
|
||||
and bots.
|
||||
|
||||
* Owners and Administrators have the ability to deactivate and
|
||||
* Owners and administrators have the ability to deactivate and
|
||||
reactivate other human and bot users, delete streams, add/remove
|
||||
administrator privileges, as well as change configuration for the
|
||||
organization.
|
||||
|
|
|
|||
|
|
@ -38,13 +38,13 @@ prefilled with that value.
|
|||
|
||||
`AUTHENTICATION_BACKENDS`: Zulip supports a wide range of popular
|
||||
options for authenticating users to your server, including Google
|
||||
Auth, GitHub Auth, LDAP, SAML, REMOTE_USER, and more.
|
||||
auth, GitHub auth, LDAP, SAML, REMOTE_USER, and more.
|
||||
|
||||
If you want an additional or different authentication backend, you
|
||||
will need to uncomment one or more and then do any additional
|
||||
configuration required for that backend as documented in the
|
||||
`settings.py` file. See the
|
||||
[section on Authentication](../production/authentication-methods.md) for more
|
||||
[section on authentication](../production/authentication-methods.md) for more
|
||||
detail on the available authentication backends and how to configure
|
||||
them.
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ and restart various services.
|
|||
|
||||
### Checking status with `supervisorctl status`
|
||||
|
||||
You can check if the zulip application is running using:
|
||||
You can check if the Zulip application is running using:
|
||||
```
|
||||
supervisorctl status
|
||||
```
|
||||
|
|
@ -93,10 +93,10 @@ The Zulip application uses several major open source services to store
|
|||
and cache data, queue messages, and otherwise support the Zulip
|
||||
application:
|
||||
|
||||
* postgresql
|
||||
* rabbitmq-server
|
||||
* nginx
|
||||
* redis
|
||||
* PostgreSQL
|
||||
* RabbitMQ
|
||||
* Nginx
|
||||
* Redis
|
||||
* memcached
|
||||
|
||||
If one of these services is not installed or functioning correctly,
|
||||
|
|
@ -140,11 +140,11 @@ problems and how to resolve them:
|
|||
<https://linoxide.com/ubuntu-how-to/enable-disable-unattended-upgrades-ubuntu-16-04/>`_
|
||||
and instead install apt upgrades manually. With unattended upgrades
|
||||
enabled, the moment a new Postgres release is published, your Zulip
|
||||
server will have its postgres server upgraded (and thus restarted).
|
||||
server will have its Postgres server upgraded (and thus restarted).
|
||||
```
|
||||
|
||||
Restarting one of the system services that Zulip uses (`postgres`,
|
||||
`memcached`, `redis`, or `rabbitmq`) will drop the connections that
|
||||
Restarting one of the system services that Zulip uses (Postgres,
|
||||
memcached, Redis, or Rabbitmq) will drop the connections that
|
||||
Zulip processes have to the service, resulting in future operations on
|
||||
those connections throwing errors.
|
||||
|
||||
|
|
@ -165,8 +165,8 @@ workers are commonly idle for periods of hours or days at a time.
|
|||
You can prevent this trickle when doing a planned upgrade by
|
||||
restarting the Zulip server with
|
||||
`/home/zulip/deployments/current/scripts/restart-server` after
|
||||
installing system package updates to `postgres`, `memcached`,
|
||||
`rabbitmq`, or `redis`.
|
||||
installing system package updates to Postgres, memcached,
|
||||
RabbitMQ, or Redis.
|
||||
|
||||
Few system administrators enjoy outages at random times (even if only
|
||||
brief) or the resulting distribution of error emails, which is why we
|
||||
|
|
@ -189,8 +189,8 @@ standard stuff:
|
|||
especially for the database and where uploads are stored.
|
||||
* Service uptime and standard monitoring for the [services Zulip
|
||||
depends on](#troubleshooting-services). Most monitoring software
|
||||
has standard plugins for `nginx`, `postgres`, `redis`, `rabbitmq`,
|
||||
and `memcached`, and those will work well with Zulip.
|
||||
has standard plugins for Nginx, Postgres, Redis, RabbitMQ,
|
||||
and memcached, and those will work well with Zulip.
|
||||
* `supervisorctl status` showing all services `RUNNING`.
|
||||
* Checking for processes being OOM killed.
|
||||
|
||||
|
|
@ -230,8 +230,8 @@ Database monitoring:
|
|||
* `check_fts_update_log`: Checks whether full-text search updates are
|
||||
being processed properly or getting backlogged.
|
||||
* `check_postgres`: General checks for database health.
|
||||
* `check_postgres_backup`: Checks status of postgres backups.
|
||||
* `check_postgres_replication_lag`: Checks whether postgres streaming
|
||||
* `check_postgres_backup`: Checks status of Postgres backups.
|
||||
* `check_postgres_replication_lag`: Checks whether Postgres streaming
|
||||
replication is up to date.
|
||||
|
||||
Standard server monitoring:
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
This page explains how to upgrade, patch, or modify Zulip, including:
|
||||
|
||||
- [Upgrading to a release](#upgrading-to-a-release)
|
||||
- [Upgrading from a git repository](#upgrading-from-a-git-repository)
|
||||
- [Upgrading from a Git repository](#upgrading-from-a-git-repository)
|
||||
- [Troubleshooting and rollback](#troubleshooting-and-rollback)
|
||||
- [Preserving local changes to configuration files](#preserving-local-changes-to-configuration-files)
|
||||
- [Upgrading the operating system](#upgrading-the-operating-system)
|
||||
|
|
@ -166,7 +166,7 @@ the version corresponding to the `restart-server` path you call.
|
|||
|
||||
You can test whether this will happen assuming no upstream changes to
|
||||
the configuration using `scripts/zulip-puppet-apply` (without the
|
||||
`-f` option), which will do a test puppet run and output and changes
|
||||
`-f` option), which will do a test Puppet run and output and changes
|
||||
it would make. Using this list, you can save a copy of any files
|
||||
that you've modified, do the upgrade, and then restore your
|
||||
configuration.
|
||||
|
|
@ -177,7 +177,7 @@ system to Zulip Cloud. Before making local changes to a configuration
|
|||
file, first check whether there's an option supported by
|
||||
`/etc/zulip/zulip.conf` for the customization you need. And if you
|
||||
need to make local modifications, please report the issue so that we
|
||||
can make the Zulip puppet configuration flexible enough to handle your
|
||||
can make the Zulip Puppet configuration flexible enough to handle your
|
||||
setup.
|
||||
|
||||
### nginx configuration changes
|
||||
|
|
@ -195,7 +195,7 @@ some additional steps to update your Zulip installation, documented
|
|||
below.
|
||||
|
||||
The steps are largely the same for the various OS upgrades aside from
|
||||
the versions of postgres, so you should be able to adapt these
|
||||
the versions of Postgres, so you should be able to adapt these
|
||||
instructions for other supported platforms.
|
||||
|
||||
### Upgrading from Ubuntu 18.04 Bionic to 20.04 Focal
|
||||
|
|
@ -226,8 +226,8 @@ instructions for other supported platforms.
|
|||
release update of Ubuntu 20.04 LTS is released.
|
||||
|
||||
When `do-release-upgrade` asks you how to upgrade configuration
|
||||
files for services that Zulip manages like `redis`, `postgres`,
|
||||
`nginx`, and `memcached`, the best choice is `N` to keep the
|
||||
files for services that Zulip manages like Redis, Postgres,
|
||||
Nginx, and memcached, the best choice is `N` to keep the
|
||||
currently installed version. But it's not important; the next
|
||||
step will re-install Zulip's configuration in any case.
|
||||
|
||||
|
|
@ -357,8 +357,8 @@ instructions for other supported platforms.
|
|||
[debian-upgrade-os]: https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.html
|
||||
|
||||
When prompted for you how to upgrade configuration
|
||||
files for services that Zulip manages like `redis`, `postgres`,
|
||||
`nginx`, and `memcached`, the best choice is `N` to keep the
|
||||
files for services that Zulip manages like Redis, Postgres,
|
||||
Nginx, and memcached, the best choice is `N` to keep the
|
||||
currently installed version. But it's not important; the next
|
||||
step will re-install Zulip's configuration in any case.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ designed around the following goals:
|
|||
- Efficient to query so that we can display data in-app (e.g. on the streams
|
||||
page) with minimum impact on the overall performance of those pages.
|
||||
- Storage size smaller than the size of the main Message/UserMessage
|
||||
database tables, so that we can store the data in the main postgres
|
||||
database tables, so that we can store the data in the main Postgres
|
||||
database rather than using a specialized database platform.
|
||||
|
||||
There are a few important things you need to understand in order to
|
||||
|
|
@ -64,7 +64,7 @@ summed to rows in InstallationCount with totals for pairs of (end_time,
|
|||
client).
|
||||
|
||||
Note: In most cases, we do not store rows with value 0. See
|
||||
[Performance Strategy](#performance-strategy) below.
|
||||
[Performance strategy](#performance-strategy) below.
|
||||
|
||||
## CountStats
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ presented [here](https://packaging.python.org/tutorials/installing-packages/).
|
|||
|
||||
2. Create a [source distribution][3].
|
||||
|
||||
3. Create a [pure Python Wheel][4].
|
||||
3. Create a [pure Python wheel][4].
|
||||
|
||||
4. [Upload][5] the distribution file(s) to [zulip-beta][6].
|
||||
|
||||
|
|
|
|||
|
|
@ -104,12 +104,12 @@ files from S3. Finally, `Attachment`'s `m2m` relationship ties to
|
|||
Here are the same classes of data, listed in roughly
|
||||
decreasing order of riskiness:
|
||||
|
||||
- Message Data (sheer volume/lack of time/security)
|
||||
- File-Related Data (S3/security/lots of moving parts)
|
||||
- Recipient Data (complexity/security/cross-realm considerations)
|
||||
- Cross Realm Data (duplicate ids)
|
||||
- Disjoint User Data
|
||||
- Public Realm Data
|
||||
- Message data (sheer volume/lack of time/security)
|
||||
- File-related data (S3/security/lots of moving parts)
|
||||
- Recipient data (complexity/security/cross-realm considerations)
|
||||
- Cross realm data (duplicate ids)
|
||||
- Disjoint user data
|
||||
- Public realm data
|
||||
|
||||
(Note the above list is essentially in reverse order of how we
|
||||
process the data, which isn't surprising for a top-down approach.)
|
||||
|
|
|
|||
|
|
@ -53,17 +53,17 @@ can be the source of the stimulus, or the target of the response,
|
|||
or both. Along those lines, we divide custom apps into
|
||||
these three types:
|
||||
|
||||
- A **Zulip Reader** uses activity on Zulip to stimulate an external
|
||||
- A **Zulip reader** uses activity on Zulip to stimulate an external
|
||||
response. An example here would be a follow-up bot that sees
|
||||
messages with the alert word "@todo" on a stream and then
|
||||
adds a task to a third party todo-list tool.
|
||||
|
||||
- A **Zulip Writer** reacts to external stimuli and generates
|
||||
- A **Zulip writer** reacts to external stimuli and generates
|
||||
Zulip responses. An example here might be a build bot that
|
||||
gets triggered by an automated code build finishing and then
|
||||
writes "build finished" to a Zulip stream.
|
||||
|
||||
- A **Zulip Read/Writer** reacts to a stimulus from Zulip by
|
||||
- A **Zulip reader/writer** reacts to a stimulus from Zulip by
|
||||
responding to Zulip. An example here would be a math bot
|
||||
that sees a message saying "compute 2+2" and responds with
|
||||
"2+2=4" on the same stream or back to the user in a PM.
|
||||
|
|
@ -72,16 +72,16 @@ The above three classifications represent kind of a Zulip-centric
|
|||
view of the universe, but we should put ourselves in the shoes
|
||||
of somebody "out in the world."
|
||||
|
||||
- A **World Reader** is an app that gets some stimulus from
|
||||
- A **world reader** is an app that gets some stimulus from
|
||||
the outside world and produces a response in Zulip. (So, a world
|
||||
reader is a Zulip writer.)
|
||||
|
||||
- A **World Writer** is an app that gets some stimulus from
|
||||
- A **world writer** is an app that gets some stimulus from
|
||||
Zulip and produces a response in the outside world. (So, a world
|
||||
writer is a Zulip reader.)
|
||||
|
||||
Some things are a little outside of the scope of this document.
|
||||
We could plausibly extend Zulip some day to host **World Reader/Writer**
|
||||
We could plausibly extend Zulip some day to host **world reader/Writer**
|
||||
apps that don't even write Zulip messages but simply use
|
||||
Zulip as a kind of middleware platform.
|
||||
|
||||
|
|
@ -93,14 +93,14 @@ the scope of this document, we won't spend a lot of time talking
|
|||
about how to build these types of apps, but we are aware that
|
||||
any solution needs to accommodate multiple sources and targets.
|
||||
|
||||
### World Reader/Zulip Reader
|
||||
### World reader/Zulip reader
|
||||
|
||||
Finally, we set the stage for how we talk about custom apps in
|
||||
terms of these two broad categories:
|
||||
|
||||
- A **World Reader** responds to stimuli from the outside world (and
|
||||
- A **world reader** responds to stimuli from the outside world (and
|
||||
typically produces a response in Zulip).
|
||||
- A **Zulip Reader** responds to stimuli from Zulip conversations (and
|
||||
- A **Zulip reader** responds to stimuli from Zulip conversations (and
|
||||
typically produces a response in the outside world).
|
||||
|
||||
Again, we recognize that there can be overlap between those two
|
||||
|
|
@ -152,9 +152,9 @@ party corporate system based on Zulip events, I may want to deploy code
|
|||
to a public webserver or try to get my code to be part of the
|
||||
Zulip project itself.
|
||||
|
||||
## World Reader
|
||||
## World reader
|
||||
|
||||
A **World Reader** custom app is an app that responds to stimuli
|
||||
A **world reader** custom app is an app that responds to stimuli
|
||||
from the world outside of Zulip. It typically functions as a **Zulip
|
||||
Writer** and posts some kind of message to a Zulip stream or user to
|
||||
alert people of world events. Here are some example stimuli:
|
||||
|
|
@ -175,11 +175,11 @@ you basically have to solve these problems:
|
|||
### Zulip integrations
|
||||
|
||||
Zulip actually supports a bunch of integrations out-of-the-box that
|
||||
perform as **World Readers**.
|
||||
perform as **world readers**.
|
||||
|
||||
The [three different integration models](https://zulip.com/api/integrations-overview#sending-content-into-zulip)
|
||||
basically differ in where they perform the main functions of a
|
||||
**World Reader**.
|
||||
**world reader**.
|
||||
|
||||
#### Incoming webhook integrations
|
||||
|
||||
|
|
@ -240,21 +240,21 @@ Ruby. There are probably still some scenarios, however, where a lot of the
|
|||
logic for translation could be moved to a Zulip-side integration, and then we
|
||||
supply very thin client code for the plugin.
|
||||
|
||||
## Zulip Reader
|
||||
## Zulip reader
|
||||
|
||||
A **Zulip Reader** custom app gets stimuli from Zerver itself. Most
|
||||
**Zulip Reader** apps are packaged/advertised more as what people commonly call
|
||||
A **Zulip reader** custom app gets stimuli from Zerver itself. Most
|
||||
**Zulip reader** apps are packaged/advertised more as what people commonly call
|
||||
"bots" than as "integrations." (But sometimes what is currently a "bot" should really
|
||||
be deployed more like an "integration" in an ideal Zulip universe.)
|
||||
|
||||
Example custom **Zulip Reader** apps can be serious or whimsical.
|
||||
Example custom **Zulip reader** apps can be serious or whimsical.
|
||||
|
||||
**Serious**
|
||||
|
||||
- A user tags a message with an alert word like `@followup` or `@ticket`.
|
||||
- A user needs help computing something, like a simple math expression
|
||||
or a timezone conversion.
|
||||
- A **World Reader** custom app posts something to a Zulip stream that we
|
||||
- A **world reader** custom app posts something to a Zulip stream that we
|
||||
want to cross-post to another external system.
|
||||
- A user wants the custom app to query the outside world, like look up the
|
||||
weather or search Wikipedia.
|
||||
|
|
@ -267,7 +267,7 @@ weather or search Wikipedia.
|
|||
- A user wants to tell the office telepresence robot to "turn left."
|
||||
|
||||
Setting aside whether a custom app is performing a serious or whimsical
|
||||
function, there are a few different types of **Zulip Readers**:
|
||||
function, there are a few different types of **Zulip readers**:
|
||||
|
||||
- Some readers will do simple local computations and post right back to Zulip.
|
||||
- Some readers will do more expensive/web-related computations like searching
|
||||
|
|
@ -303,7 +303,7 @@ code to your friends and have them be able to deploy it.
|
|||
- If you've written a general-use bot, it may be difficult to persuade your
|
||||
admin to give you a superuser account.
|
||||
|
||||
We want to make it easier to deploy **Zulip Readers** on
|
||||
We want to make it easier to deploy **Zulip readers** on
|
||||
Zulip hardware. The following document talks about how we want to enable this
|
||||
from a code structuring standpoint:
|
||||
|
||||
|
|
@ -326,7 +326,7 @@ apps, where an app author might use the following development process:
|
|||
|
||||
To give a concrete example, let's say that I work for a company that is
|
||||
building an issue tracker, and we want to offer Zulip support. I would
|
||||
start by writing a **Zulip Reader** that scans for the alert word `@ticket`
|
||||
start by writing a **Zulip reader** that scans for the alert word `@ticket`
|
||||
on certain public Zulip streams, and part of that app would have logic
|
||||
to post to my company's issue-tracking API.
|
||||
|
||||
|
|
@ -360,7 +360,7 @@ the "world" as it sees fit.
|
|||
### Zulip-side support for reader apps
|
||||
|
||||
Even for app authors that have access to dedicated hardware,
|
||||
there would be several advantages to running **Zulip Readers** under
|
||||
there would be several advantages to running **Zulip readers** under
|
||||
the same umbrella as the core Zulip system.
|
||||
|
||||
- Your app will automatically inherit the uptime of the Zulip server itself (in
|
||||
|
|
@ -382,7 +382,7 @@ the problems below. (One assumption is that we don't run apps truly
|
|||
in-process.)
|
||||
|
||||
- **Contributions**: We need a process for users to contribute code.
|
||||
- **Configuration/Discovery**: We need Zulip to be able to find which
|
||||
- **Configuration/discovery**: We need Zulip to be able to find which
|
||||
apps are allowed to run for a particular
|
||||
deployment. (The admin may choose to run only a subset of contributed
|
||||
apps.)
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ on specific versions of these packages wherever possible.
|
|||
|
||||
The exact lists of `apt` packages needed by Zulip are maintained in a
|
||||
few places:
|
||||
* For production, in our puppet configuration, `puppet/zulip/`, using
|
||||
* For production, in our Puppet configuration, `puppet/zulip/`, using
|
||||
the `Package` and `SafePackage` directives.
|
||||
* For development, in `SYSTEM_DEPENDENCIES` in `tools/lib/provision.py`.
|
||||
* The packages needed to build a Zulip virtualenv, in
|
||||
|
|
@ -113,7 +113,7 @@ few places:
|
|||
install other dependencies, and (2) because that list is shared
|
||||
between development and production.
|
||||
|
||||
We also rely on the `pgroonga` PPA for the `pgroonga` postgres
|
||||
We also rely on the PGroonga PPA for the PGroonga Postgres
|
||||
extension, used by our [full-text search](full-text-search.md).
|
||||
|
||||
## Python packages
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Currently, Zulip supports these four display formats for emoji:
|
|||
## Emoji codes
|
||||
|
||||
The Unicode standard has various ranges of characters set aside for
|
||||
emoji. So you can put emoji in your terminal using actual unicode
|
||||
emoji. So you can put emoji in your terminal using actual Unicode
|
||||
characters like 😀 and 👍. If you paste those into Zulip, Zulip will
|
||||
render them as the corresponding emoji image.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ etc. However, we can't use the sprite sheets in some contexts, such
|
|||
as missed-message and digest emails, that need to have self-contained
|
||||
assets. For those, we use individual emoji files under
|
||||
`static/generated/emoji`. The structure of that repository contains
|
||||
both files named after the unicode representation of emoji (as actual
|
||||
both files named after the Unicode representation of emoji (as actual
|
||||
image files) as well as symlinks pointing to those emoji.
|
||||
|
||||
We need to maintain those both for the names used in the iamcal emoji
|
||||
|
|
@ -69,7 +69,7 @@ for more details on this strategy.
|
|||
|
||||
The emoji tree generated by this process contains several import elements:
|
||||
* `emoji_codes.json`: A set of mappings used by the Zulip frontend to
|
||||
understand what unicode emoji exist and what their shortnames are,
|
||||
understand what Unicode emoji exist and what their shortnames are,
|
||||
used for autocomplete, emoji pickers, etc. This has been
|
||||
deduplicated using the logic in
|
||||
`tools/setup/emoji/emoji_setup_utils.py` to generally only have
|
||||
|
|
@ -80,7 +80,7 @@ The emoji tree generated by this process contains several import elements:
|
|||
`images/emoji/unicode/` tree. This is used to serve individual emoji
|
||||
images, as well as for the
|
||||
[backend Markdown processor](../subsystems/markdown.md) to know which emoji
|
||||
names exist and what unicode emoji / images they map to. In this
|
||||
names exist and what Unicode emoji / images they map to. In this
|
||||
tree, we currently include all of the emoji in `emoji-map.json`;
|
||||
this means that if you send `:angry_face:`, it won't autocomplete,
|
||||
but will still work (but not in previews).
|
||||
|
|
@ -131,7 +131,7 @@ principles that were applied to the current set of names. We use (strong),
|
|||
be familiar to a large subset of users. This largely applies to certain
|
||||
faces. (medium)
|
||||
|
||||
* The set of names should be compatible with the iamcal, gemoji, and unicode
|
||||
* The set of names should be compatible with the iamcal, gemoji, and Unicode
|
||||
names. Compatible here means that if there is an emoji name a user knows
|
||||
from one of those sets, and the user searches for the key word of that
|
||||
name, they will get an emoji in our set. It is okay if this emoji has a
|
||||
|
|
|
|||
|
|
@ -137,8 +137,8 @@ Important considerations for any changes are:
|
|||
Zulip's Markdown processor's rendering supports a number of features
|
||||
that depend on realm-specific or user-specific data. For example, the
|
||||
realm could have
|
||||
[Linkifiers](https://zulip.com/help/add-a-custom-linkification-filter)
|
||||
or [Custom emoji](https://zulip.com/help/add-custom-emoji)
|
||||
[linkifiers](https://zulip.com/help/add-a-custom-linkification-filter)
|
||||
or [custom emoji](https://zulip.com/help/add-custom-emoji)
|
||||
configured, and Zulip supports mentions for streams, users, and user
|
||||
groups (which depend on data like users' names, IDs, etc.).
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ accurate.
|
|||
`http://google.com`, and not `https://zulip.com/google.com` which
|
||||
is the default behavior.
|
||||
|
||||
* Set `title=`(the url) on every link tag.
|
||||
* Set `title=`(the URL) on every link tag.
|
||||
|
||||
* Disable link-by-reference syntax,
|
||||
`[foo][bar]` ... `[bar]: https://google.com`.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ migrations.
|
|||
to the table, performing data backfills, or building indexes. We
|
||||
have a `zerver/lib/migrate.py` library to help with adding columns
|
||||
and backfilling data. For building indexes on these tables, we
|
||||
should do this using SQL with postgres's CONCURRENTLY keyword.
|
||||
should do this using SQL with Postgres's CONCURRENTLY keyword.
|
||||
|
||||
* **Atomicity**. By default, each Django migration is run atomically
|
||||
inside a transaction. This can be problematic if one wants to do
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ system and possibly improve it. This document assumes that the
|
|||
client is our web app, but any client can play along with this
|
||||
protocol.
|
||||
|
||||
Right now typing indicators are only used in "Private Messages"
|
||||
Right now typing indicators are only used in "Private messages"
|
||||
views.
|
||||
|
||||
There are two major roles for users in this system:
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ All users can...
|
|||
- show up in your message stream
|
||||
- be narrowed to by clicking on recipient bars, etc.
|
||||
- be narrowed to by searches (but not suggested)
|
||||
- can show up in your "Private Messages" sidebar
|
||||
- can show up in your "Private messages" sidebar
|
||||
|
||||
We also have the mirroring world, where we have unknown users
|
||||
that we can send PMs to, and local-echo is allowed to create
|
||||
|
|
|
|||
|
|
@ -17,10 +17,10 @@ prevent common coding errors.
|
|||
We borrow some open source tools for much of our linting, and the links
|
||||
below will direct you to the official documentation for these projects.
|
||||
|
||||
- [eslint](https://eslint.org)
|
||||
- [ESLint](https://eslint.org)
|
||||
- [mypy](http://mypy-lang.org/)
|
||||
- [Prettier](https://prettier.io/)
|
||||
- [puppet](https://puppet.com/) (puppet provides its own mechanism for
|
||||
- [Puppet](https://puppet.com/) (puppet provides its own mechanism for
|
||||
validating manifests)
|
||||
- [pyflakes](https://pypi.python.org/pypi/pyflakes)
|
||||
- [stylelint](https://github.com/stylelint/stylelint)
|
||||
|
|
@ -100,11 +100,11 @@ Most of our lint checks get performed by `./tools/lint`. These include the
|
|||
following checks:
|
||||
|
||||
- Check Python code with pyflakes.
|
||||
- Check JavaScript and TypeScript code with eslint.
|
||||
- Check JavaScript and TypeScript code with ESLint.
|
||||
- Check CSS, JavaScript, TypeScript, and YAML formatting with Prettier.
|
||||
- Check Python code for custom Zulip rules.
|
||||
- Check non-Python code for custom Zulip rules.
|
||||
- Check puppet manifests with the puppet validator.
|
||||
- Check Puppet manifests with the Puppet validator.
|
||||
- Check HTML templates for matching tags and indentations.
|
||||
- Check CSS for parsability and formatting.
|
||||
- Check JavaScript code for addClass calls.
|
||||
|
|
@ -136,7 +136,7 @@ types of checks mostly lives [here](https://github.com/zulip/zulip/blob/master/t
|
|||
|
||||
You can use the `-h` option for `lint` to see its usage. One particular
|
||||
flag to take note of is the `--modified` flag, which enables you to only run
|
||||
lint checks against files that are modified in your git repo. Most of the
|
||||
lint checks against files that are modified in your Git repo. Most of the
|
||||
"sub-linters" respect this flag, but some will continue to process all the files.
|
||||
Generally, a good workflow is to run with `--modified` when you are iterating on
|
||||
the code, and then run without that option right before committing new code.
|
||||
|
|
@ -190,8 +190,8 @@ We check our JavaScript code in a few different ways:
|
|||
#### Puppet manifests
|
||||
|
||||
We use Puppet as our tool to manage configuration files, using
|
||||
puppet "manifests." To lint puppet manifests, we use the "parser validate"
|
||||
option of puppet.
|
||||
Puppet "manifests." To lint Puppet manifests, we use the "parser validate"
|
||||
option of Puppet.
|
||||
|
||||
#### HTML templates
|
||||
|
||||
|
|
|
|||
|
|
@ -181,10 +181,10 @@ For each of the above types of messages, you will want to cycle
|
|||
through the following views for Cordelia (and have Hamlet send new
|
||||
messages after each narrow):
|
||||
|
||||
- Go to All Messages view.
|
||||
- Go to Private Messages view.
|
||||
- Go to Private Messages w/Hamlet.
|
||||
- Go to Private Messages w/Hamlet and Othello.
|
||||
- Go to All messages view.
|
||||
- Go to Private messages view.
|
||||
- Go to Private messages w/Hamlet.
|
||||
- Go to Private messages w/Hamlet and Othello.
|
||||
- Go to Verona view.
|
||||
- Go to Verona/bar view.
|
||||
- Go to Verona/foo view.
|
||||
|
|
@ -212,9 +212,9 @@ populated and where the focus is placed.
|
|||
|
||||
- Buttons
|
||||
- Narrow to a stream and click on "New topic"
|
||||
- Narrow "Private Messages" and click on "New topic"
|
||||
- Narrow "Private messages" and click on "New topic"
|
||||
- Narrow to a stream and click on "New private message"
|
||||
- Narrow "Private Messages" and click on "New private message"
|
||||
- Narrow "Private messages" and click on "New private message"
|
||||
|
||||
- Topics
|
||||
- Compose/send a message to a stream with no topic.
|
||||
|
|
@ -468,7 +468,7 @@ Do these tasks as Cordelia.
|
|||
- Show user list on left sidebar in narrow windows (verify by making window thinner)
|
||||
- 24-hour time (and then test going back to AM/PM)
|
||||
- Notifications
|
||||
- Stream Message
|
||||
- Stream message
|
||||
- turn off notifications at user level
|
||||
- create a new stream
|
||||
- have Hamlet send a message
|
||||
|
|
@ -477,7 +477,7 @@ Do these tasks as Cordelia.
|
|||
- have Hamlet send a message
|
||||
- then turn off notifications for that stream
|
||||
- have Hamlet send another message
|
||||
- Private Messages and @-mentions
|
||||
- Private messages and @-mentions
|
||||
- Test Desktop/Audible options
|
||||
- You can ignore other stuff for now
|
||||
- Bots/API key
|
||||
|
|
|
|||
|
|
@ -66,9 +66,9 @@ these goals, but a few techniques are worth highlighting:
|
|||
outgoing HTTP requests are required to test something, we mock the
|
||||
responses with libraries like `responses`.
|
||||
* We carefully avoid the potential for contamination of data inside
|
||||
services like postgres, redis, and memcached from different tests.
|
||||
services like Postgres, Redis, and memcached from different tests.
|
||||
* Every test case prepends a unique random prefix to all keys it
|
||||
uses when accessing redis and memcached.
|
||||
uses when accessing Redis and memcached.
|
||||
* Every test case runs inside a database transaction, which is
|
||||
aborted after the test completes. Each test process interacts
|
||||
only with a fresh copy of a special template database used for
|
||||
|
|
|
|||
|
|
@ -203,7 +203,7 @@ These instructions assume you're using the Vagrant development environment.
|
|||
1. In the `Configure Node.js Remote Interpreter`, window select `Vagrant`
|
||||
1. Wait for WebStorm to connect to Vagrant. This will be displayed
|
||||
by the `Vagrant Host URL` section updating to contain the Vagrant
|
||||
SSH url, e.g. `ssh://vagrant@127.0.0.1:2222`.
|
||||
SSH URL, e.g. `ssh://vagrant@127.0.0.1:2222`.
|
||||
1. **Set the `Node.js interpreter path` to `/usr/local/bin/node`**
|
||||
1. Hit `OK` 2 times to get back to the `Run/Debug Configurations` window.
|
||||
1. Under `Working Directory` select the root `zulip` directory.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The test files live in `frontend_tests/puppeteer_tests` and make use
|
|||
of various useful helper functions defined in
|
||||
`frontend_tests/puppeteer_lib/common.js`.
|
||||
|
||||
## How puppeteer tests work
|
||||
## How Puppeteer tests work
|
||||
|
||||
The Puppeteer tests use a real Chromium browser (powered by
|
||||
[puppeteer](https://github.com/puppeteer/puppeteer)), connected to a
|
||||
|
|
@ -93,7 +93,7 @@ These tools/features are often useful when debugging:
|
|||
debugging test failures.
|
||||
* TODO: Mention how to access Puppeteer screenshots in CI.
|
||||
* TODO: Add an option for using the `headless: false` debugging mode
|
||||
of puppeteer so you can watch what's happening, and document how to
|
||||
of Puppeteer so you can watch what's happening, and document how to
|
||||
make that work with Vagrant.
|
||||
* TODO: Document `--interactive`.
|
||||
* TODO: Document how to run 100x in CI to check for nondeterminstic
|
||||
|
|
@ -108,7 +108,7 @@ These tools/features are often useful when debugging:
|
|||
includes the console output for the server; any Python exceptions
|
||||
are likely actual bugs in the changes being tested.
|
||||
|
||||
See also [puppeteer upstream's debugging
|
||||
See also [Puppeteer upstream's debugging
|
||||
tips](https://github.com/puppeteer/puppeteer#debugging-tips); some
|
||||
tips may require temporary patches to functions like `run_test` or
|
||||
`ensure_browser` in `frontend_tests/puppeteer_lib/common.js`.
|
||||
|
|
@ -153,4 +153,3 @@ notes above:
|
|||
`zilencer/management/commands/populate_db.py`.
|
||||
|
||||
[learn-async-await]: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ code paths (`httplib2.Http().request`, `requests.request`, etc.) to
|
|||
throw an exception in the backend tests. While this is enforcement is
|
||||
not complete (there a lot of other ways to use the Internet from
|
||||
Python), it is easy to do and catches most common cases of new code
|
||||
dependning on Internet access.
|
||||
depending on Internet access.
|
||||
|
||||
This enforcement code results in the following exception:
|
||||
|
||||
|
|
|
|||
|
|
@ -137,7 +137,7 @@ Since we try to avoid concatenating words whenever possible, don't use
|
|||
"Privatnachricht" . PN is the officially used abbreviation for
|
||||
"Private Nachricht" and is used in many German chat forums.
|
||||
|
||||
*"Private Nachricht" (Youtube, Transifex)*
|
||||
*"Private Nachricht" (YouTube, Transifex)*
|
||||
|
||||
* Starred Message - **Markierte Nachricht**
|
||||
|
||||
|
|
@ -260,7 +260,7 @@ works as well, but is not that common in German.
|
|||
|
||||
This translation is unambiguous.
|
||||
|
||||
*"Deabonnieren" (Youtube, Transifex)*
|
||||
*"Deabonnieren" (YouTube, Transifex)*
|
||||
|
||||
* Narrow to - **Begrenzen auf**
|
||||
|
||||
|
|
@ -293,7 +293,7 @@ preferable due to its brevity.
|
|||
|
||||
* Search - **Suchen**
|
||||
|
||||
*"Suchen" (Youtube, Google, Facebook, Transifex)*
|
||||
*"Suchen" (YouTube, Google, Facebook, Transifex)*
|
||||
|
||||
* Pin/Unpin - **Anpinnen/Loslösen**
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ There are a few ways to see your translations in the Zulip UI:
|
|||
out the language the user requests in a browser using the following
|
||||
prioritization (mostly copied from the Django docs):
|
||||
|
||||
1. It looks for the language code as a url prefix (e.g. `/de/login/`).
|
||||
1. It looks for the language code as a URL prefix (e.g. `/de/login/`).
|
||||
2. It looks for the `LANGUAGE_SESSION_KEY` key in the current user's
|
||||
session (the Zulip language UI option ends up setting this).
|
||||
3. It looks for the cookie named 'django_language'. You can set a
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ application will serve the request (or deciding to serve the request
|
|||
itself for static content).
|
||||
|
||||
In development, `tools/run-dev.py` fills the role of nginx. Static files
|
||||
are in your git checkout under `static`, and are served unminified.
|
||||
are in your Git checkout under `static`, and are served unminified.
|
||||
|
||||
## Static files are [served directly][served-directly] by Nginx
|
||||
|
||||
|
|
@ -167,7 +167,7 @@ its url patterns (see
|
|||
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py))
|
||||
so that the action called is `rest_dispatch`. This method will
|
||||
authenticate the user, either through a session token from a cookie,
|
||||
or from an `email:api-key` string given via HTTP Basic Auth for API
|
||||
or from an `email:api-key` string given via HTTP basic auth for API
|
||||
clients.
|
||||
|
||||
It will then look up what HTTP verb was used (GET, POST, etc) to make
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ document it and update any existing documentation that might be
|
|||
relevant to the new feature. For more information on the kinds of
|
||||
documentation Zulip has, see [Documentation](../documentation/overview.md).
|
||||
|
||||
## Example Feature
|
||||
## Example feature
|
||||
|
||||
This example describes the process of adding a new setting to Zulip: a
|
||||
flag that allows an admin to require topics on stream messages (the default
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ which is documented in detail at
|
|||
[zerver/lib/rest.py](https://github.com/zulip/zulip/blob/master/zerver/lib/rest.py).
|
||||
This method will authenticate the user either through a session token
|
||||
from a cookie on the browser, or from a base64 encoded `email:api-key`
|
||||
string given via HTTP Basic Auth for API clients.
|
||||
string given via HTTP basic auth for API clients.
|
||||
|
||||
``` py
|
||||
>>> import requests
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ run_test("title_data", () => {
|
|||
};
|
||||
assert.deepEqual(buddy_data.get_title_data(bot.user_id, is_group), expected_group_data);
|
||||
|
||||
// Individual Users.
|
||||
// Individual users.
|
||||
user_status.set_status_text({
|
||||
user_id: me.user_id,
|
||||
status_text: "out to lunch",
|
||||
|
|
|
|||
|
|
@ -369,7 +369,7 @@ run_test("update_user_event", (override) => {
|
|||
that happen during an event. This concept is called "mocking",
|
||||
and you can find libraries to help do mocking. Here we will
|
||||
just build our own lightweight mocking system, which is almost
|
||||
trivially easy to do in a language like Javascript.
|
||||
trivially easy to do in a language like JavaScript.
|
||||
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -223,11 +223,11 @@ run_test("markdown_detection", () => {
|
|||
"https://zulip.com/image.jpg too",
|
||||
"Contains a zulip.com/foo.jpeg file",
|
||||
"Contains a https://zulip.com/image.png file",
|
||||
"twitter url https://twitter.com/jacobian/status/407886996565016579",
|
||||
"Twitter URL https://twitter.com/jacobian/status/407886996565016579",
|
||||
"https://twitter.com/jacobian/status/407886996565016579",
|
||||
"then https://twitter.com/jacobian/status/407886996565016579",
|
||||
"twitter url http://twitter.com/jacobian/status/407886996565016579",
|
||||
"youtube url https://www.youtube.com/watch?v=HHZ8iqswiCw&feature=youtu.be&a",
|
||||
"Twitter URL http://twitter.com/jacobian/status/407886996565016579",
|
||||
"YouTube URL https://www.youtube.com/watch?v=HHZ8iqswiCw&feature=youtu.be&a",
|
||||
];
|
||||
|
||||
no_markup.forEach((content) => {
|
||||
|
|
@ -475,7 +475,7 @@ run_test("marked", () => {
|
|||
'<p><span aria-label="smile" class="emoji emoji-1f642" role="img" title="smile">:smile:</span></p>',
|
||||
translate_emoticons: true,
|
||||
},
|
||||
// Test HTML Escape in Custom Zulip Rules
|
||||
// Test HTML escaping in custom Zulip rules
|
||||
{
|
||||
input: "@**<h1>The Rogue One</h1>**",
|
||||
expected: "<p>@**<h1>The Rogue One</h1>**</p>",
|
||||
|
|
|
|||
|
|
@ -48,33 +48,33 @@ run_test("get_emoji_matcher", () => {
|
|||
|
||||
run_test("triage", () => {
|
||||
const alice = {name: "alice"};
|
||||
const Alicia = {name: "Alicia"};
|
||||
const alicia = {name: "Alicia"};
|
||||
const steve = {name: "steve"};
|
||||
const Stephanie = {name: "Stephanie"};
|
||||
const stephanie = {name: "Stephanie"};
|
||||
|
||||
const names = [alice, Alicia, steve, Stephanie];
|
||||
const names = [alice, alicia, steve, stephanie];
|
||||
|
||||
assert.deepEqual(
|
||||
typeahead.triage("a", names, (r) => r.name),
|
||||
{
|
||||
matches: [alice, Alicia],
|
||||
rest: [steve, Stephanie],
|
||||
matches: [alice, alicia],
|
||||
rest: [steve, stephanie],
|
||||
},
|
||||
);
|
||||
|
||||
assert.deepEqual(
|
||||
typeahead.triage("A", names, (r) => r.name),
|
||||
{
|
||||
matches: [Alicia, alice],
|
||||
rest: [steve, Stephanie],
|
||||
matches: [alicia, alice],
|
||||
rest: [steve, stephanie],
|
||||
},
|
||||
);
|
||||
|
||||
assert.deepEqual(
|
||||
typeahead.triage("S", names, (r) => r.name),
|
||||
{
|
||||
matches: [Stephanie, steve],
|
||||
rest: [alice, Alicia],
|
||||
matches: [stephanie, steve],
|
||||
rest: [alice, alicia],
|
||||
},
|
||||
);
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ run_test("triage", () => {
|
|||
typeahead.triage("fred", names, (r) => r.name),
|
||||
{
|
||||
matches: [],
|
||||
rest: [alice, Alicia, steve, Stephanie],
|
||||
rest: [alice, alicia, steve, stephanie],
|
||||
},
|
||||
);
|
||||
});
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ run_test("sort_languages", () => {
|
|||
|
||||
const a_bot = {
|
||||
email: "a_bot@zulip.com",
|
||||
full_name: "A zulip test bot",
|
||||
full_name: "A Zulip test bot",
|
||||
is_admin: false,
|
||||
is_bot: true,
|
||||
user_id: 1,
|
||||
|
|
@ -151,7 +151,7 @@ const a_bot = {
|
|||
|
||||
const a_user = {
|
||||
email: "a_user@zulip.org",
|
||||
full_name: "A zulip user",
|
||||
full_name: "A Zulip user",
|
||||
is_admin: false,
|
||||
is_bot: false,
|
||||
user_id: 2,
|
||||
|
|
|
|||
|
|
@ -123,7 +123,7 @@ async function create_stream(page) {
|
|||
await page.waitForXPath('//*[text()="Create stream"]', {visible: true});
|
||||
await common.fill_form(page, "form#stream_creation_form", {
|
||||
stream_name: "Puppeteer",
|
||||
stream_description: "Everything puppeteer",
|
||||
stream_description: "Everything Puppeteer",
|
||||
});
|
||||
await page.click(await stream_span(page, "Scotland")); // Subscribes all users from Scotland
|
||||
await page.click(await user_span(page, "cordelia")); // Add cordelia.
|
||||
|
|
@ -142,7 +142,7 @@ async function create_stream(page) {
|
|||
);
|
||||
const subscriber_count_selector = "[data-stream-name='Puppeteer'] .subscriber-count";
|
||||
assert.strictEqual(stream_name, "Puppeteer");
|
||||
assert.strictEqual(stream_description, "Everything puppeteer");
|
||||
assert.strictEqual(stream_description, "Everything Puppeteer");
|
||||
|
||||
// Assert subscriber count becomes 5(scotland(+4), cordelia(+1), othello(-1), Desdemona(+1)).
|
||||
await page.waitForFunction(
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ async function navigation_tests(page) {
|
|||
await navigate_to(page, verona_narrow, "message_feed_container");
|
||||
|
||||
// Hardcoded this instead of using `navigate_to`
|
||||
// as puppeteer cannot click hidden elements.
|
||||
// as Puppeteer cannot click hidden elements.
|
||||
await page.evaluate(() => $("a[href='#message_feed_container]'").click());
|
||||
await wait_for_tab(page, "message_feed_container");
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
* Based on diffing library difflib, a js port of the python library.
|
||||
*
|
||||
* The sole exported function diff_strings(string_0, string_1) returns a pretty-printed
|
||||
* unicode string containing their diff.
|
||||
* Unicode string containing their diff.
|
||||
*/
|
||||
|
||||
const difflib = require("difflib");
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
#!/usr/bin/env python3
|
||||
|
||||
"""
|
||||
Nagios plugin to check that the rabbitmq has the correct number of consumers.
|
||||
Nagios plugin to check that the RabbitMQ has the correct number of consumers.
|
||||
|
||||
This script just checks the contents of /var/lib/nagios_state/check-rabbitmq-consumers,
|
||||
which is generated by scripts/nagios/check-rabbitmq-consumers.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
#!/usr/bin/env python3
|
||||
|
||||
"""
|
||||
Nagios plugin to check that the rabbitmq queues are not overflowing as a result
|
||||
Nagios plugin to check that the RabbitMQ queues are not overflowing as a result
|
||||
of a stuck consumer.
|
||||
|
||||
This script just checks the contents of /var/lib/nagios_state/check-rabbitmq-results,
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
"""Nagios plugin to check the difference between the primary and
|
||||
replica Postgres servers' xlog location. Requires that the user this
|
||||
connects to postgres as has been granted the `pg_monitor` role.
|
||||
connects to Postgres as has been granted the `pg_monitor` role.
|
||||
|
||||
"""
|
||||
import re
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
#!/usr/bin/env python3
|
||||
# Processes updates to postgres Full Text Search for new/edited messages.
|
||||
# Processes updates to Postgres full-text search for new/edited messages.
|
||||
#
|
||||
# Zulip manages its postgres full-text search as follows. When the
|
||||
# content of a message is modified, a postgres trigger logs the
|
||||
# Zulip manages its Postgres full-text search as follows. When the
|
||||
# content of a message is modified, a Postgres trigger logs the
|
||||
# message ID to the `fts_update_log` table. In the background, this
|
||||
# program processes `fts_update_log`, updating the postgres full-text
|
||||
# program processes `fts_update_log`, updating the Postgres full-text
|
||||
# search column search_tsvector in the main zerver_message.
|
||||
import sys
|
||||
|
||||
|
|
@ -88,12 +88,12 @@ try:
|
|||
USING_PGROONGA = settings.USING_PGROONGA
|
||||
except ImportError:
|
||||
# process_fts_updates also supports running locally on a remote
|
||||
# postgres server; in that case, one can just connect to localhost
|
||||
# Postgres server; in that case, one can just connect to localhost
|
||||
USING_PGROONGA = False
|
||||
|
||||
# Since we don't want a hard dependency on being able to access the
|
||||
# Zulip settings (as we may not be running on a server that has that
|
||||
# data), we determine whether we're using pgroonga using
|
||||
# data), we determine whether we're using PGroonga using
|
||||
# /etc/zulip/zulip.conf.
|
||||
#
|
||||
# However, we still also check the `USING_PGROONGA` variable, since
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ class zulip::app_frontend_base {
|
|||
|
||||
if $::osfamily == 'debian' {
|
||||
# Upgrade and other tooling wants to be able to get a database
|
||||
# shell. This is not necessary on CentOS because the postgresql
|
||||
# shell. This is not necessary on CentOS because the PostgreSQL
|
||||
# package already includes the client. This may get us a more
|
||||
# recent client than the database server is configured to be,
|
||||
# ($zulip::postgres_common::version), but they're compatible.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ class zulip::base {
|
|||
# Used in scripts including install-yarn.sh
|
||||
'curl',
|
||||
'wget',
|
||||
# Used to read /etc/zulip/zulip.conf for `zulipconf` puppet function
|
||||
# Used to read /etc/zulip/zulip.conf for `zulipconf` Puppet function
|
||||
'crudini',
|
||||
# Used for tools like sponge
|
||||
'moreutils',
|
||||
|
|
@ -42,7 +42,7 @@ class zulip::base {
|
|||
$zulip::common::nagios_plugins,
|
||||
# Required for using HTTPS in apt repositories.
|
||||
'apt-transport-https',
|
||||
# Needed for the cron jobs installed by puppet
|
||||
# Needed for the cron jobs installed by Puppet
|
||||
'cron',
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# This class includes all the modules you need to install/run a Zulip installation
|
||||
# in a single container (without the database, memcached, redis services).
|
||||
# The database, memcached, redis services need to be run in separate containers.
|
||||
# in a single container (without the database, memcached, Redis services).
|
||||
# The database, memcached, Redis services need to be run in separate containers.
|
||||
# Through this split of services, it is easier to scale the services to the needs.
|
||||
class zulip::dockervoyager {
|
||||
include zulip::base
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Minimal shared configuration needed to run a Zulip postgres database.
|
||||
# Minimal shared configuration needed to run a Zulip Postgres database.
|
||||
class zulip::postgres_appdb_base {
|
||||
include zulip::postgres_common
|
||||
include zulip::process_fts_updates
|
||||
|
|
@ -33,7 +33,7 @@ class zulip::postgres_appdb_base {
|
|||
$pgroonga_setup_sql_path = "${postgres_sharedir}/pgroonga_setup.sql"
|
||||
$setup_system_deps = 'setup_yum_repo'
|
||||
$postgres_restart = "systemctl restart postgresql-${zulip::postgres_common::version}"
|
||||
# TODO Since we can't find the postgres dicts directory on CentOS yet, we
|
||||
# TODO Since we can't find the Postgres dicts directory on CentOS yet, we
|
||||
# link directly to the hunspell directory.
|
||||
$postgres_dict_dict = '/usr/share/myspell/en_US.dic'
|
||||
$postgres_dict_affix = '/usr/share/myspell/en_US.aff'
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ class zulip::rabbit {
|
|||
'debian' => 'erlang-base',
|
||||
'redhat' => 'erlang',
|
||||
}
|
||||
$rabbit_packages = [# Needed to run rabbitmq
|
||||
$rabbit_packages = [# Needed to run RabbitMQ
|
||||
$erlang,
|
||||
'rabbitmq-server',
|
||||
]
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ class zulip::tornado_sharding {
|
|||
# The file entries below serve only to initialize the sharding config files
|
||||
# with the correct default content for the "only one shard" setup. For this
|
||||
# reason they use "replace => false", because the files are managed by
|
||||
# the sharding script afterwards and puppet shouldn't overwrite them.
|
||||
# the sharding script afterwards and Puppet shouldn't overwrite them.
|
||||
file { '/etc/zulip/nginx_sharding.conf':
|
||||
ensure => file,
|
||||
owner => 'root',
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# This file is managed by puppet; local changes will be overridden.
|
||||
# This file is managed by Puppet; local changes will be overridden.
|
||||
|
||||
smtpd_banner = $myhostname ESMTP $mail_name (Zulip)
|
||||
biff = no
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
#
|
||||
# Usage: Link or copy into /etc/munin/node.d/
|
||||
#
|
||||
# No Parameters
|
||||
# No parameters
|
||||
#
|
||||
# Magic markers (optional - only used by munin-config and some
|
||||
# installation scripts):
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# A simple wildcard hostgroup
|
||||
define hostgroup {
|
||||
hostgroup_name all
|
||||
alias All Servers
|
||||
alias All servers
|
||||
members *
|
||||
}
|
||||
|
||||
|
|
@ -17,70 +17,70 @@ define hostgroup {
|
|||
|
||||
define hostgroup {
|
||||
hostgroup_name web
|
||||
alias Web Servers
|
||||
alias Web servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name frontends
|
||||
alias Frontend Web Servers
|
||||
alias Frontend web servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name staging_frontends
|
||||
alias Staging Frontend Web Servers
|
||||
alias Staging frontend web servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name prod_frontends
|
||||
alias Production Frontend Web Servers
|
||||
alias Production frontend web servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name multitornado_frontends
|
||||
alias Frontend Web Servers with multiple Tornado processes
|
||||
alias Frontend web servers with multiple Tornado processes
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name singletornado_frontends
|
||||
alias Frontend Web Servers with a single Tornado process
|
||||
alias Frontend web servers with a single Tornado process
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name redis
|
||||
alias Redis Servers
|
||||
alias Redis servers
|
||||
hostgroup_members frontends
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name zmirror
|
||||
alias Zephyr Mirror Servers
|
||||
alias Zephyr mirror servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name zmirrorp
|
||||
alias Zephyr Mirror Personals Servers
|
||||
alias Zephyr mirror personals servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name zmirror_main
|
||||
alias Zephyr Mirror Main Servers
|
||||
alias Zephyr mirror main servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name postgres
|
||||
alias PostgreSQL Servers
|
||||
alias PostgreSQL servers
|
||||
hostgroup_members postgres_appdb
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name postgres_appdb
|
||||
alias PostgreSQL App Servers
|
||||
alias PostgreSQL app servers
|
||||
hostgroup_members postgres_appdb_primary
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
hostgroup_name postgres_appdb_primary
|
||||
alias Primary PostgreSQL App Servers
|
||||
alias Primary PostgreSQL app servers
|
||||
}
|
||||
|
||||
define hostgroup {
|
||||
|
|
|
|||
|
|
@ -156,7 +156,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres autovac_freeze
|
||||
service_description Check Postgres autovac_freeze
|
||||
check_command check_postgres!zulip!nagios!autovac_freeze
|
||||
hostgroup postgres_appdb_primary
|
||||
contact_groups admins
|
||||
|
|
@ -164,7 +164,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres backends
|
||||
service_description Check Postgres backends
|
||||
check_command check_postgres!zulip!nagios!backends
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -172,7 +172,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres connection
|
||||
service_description Check Postgres connection
|
||||
check_command check_postgres!zulip!nagios!connection
|
||||
hostgroup postgres_appdb
|
||||
contact_groups page_admins
|
||||
|
|
@ -180,7 +180,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres disabled triggers
|
||||
service_description Check Postgres disabled triggers
|
||||
check_command check_postgres!zulip!nagios!disabled_triggers
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -188,7 +188,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres hitratio
|
||||
service_description Check Postgres hitratio
|
||||
check_command check_postgres!zulip!nagios!hitratio
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -196,7 +196,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres locks
|
||||
service_description Check Postgres locks
|
||||
check_command check_postgres_alert_args!zulip!nagios!locks!400!600
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -204,7 +204,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres query_time
|
||||
service_description Check Postgres query_time
|
||||
check_command check_postgres_alert_args!zulip!nagios!query_time!20 seconds!40 seconds
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -212,7 +212,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres sequence
|
||||
service_description Check Postgres sequence
|
||||
check_command check_postgres!zulip!nagios!sequence
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -220,7 +220,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres timesync
|
||||
service_description Check Postgres timesync
|
||||
check_command check_postgres!zulip!nagios!timesync
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -228,7 +228,7 @@ define service {
|
|||
|
||||
# define service {
|
||||
# use generic-service
|
||||
# service_description Check postgres txn_idle
|
||||
# service_description Check Postgres txn_idle
|
||||
# check_command check_postgres_alert_args!zulip!nagios!txn_idle!20 seconds!40 seconds
|
||||
# hostgroup postgres_appdb
|
||||
# contact_groups admins
|
||||
|
|
@ -236,7 +236,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check postgres txn_time
|
||||
service_description Check Postgres txn_time
|
||||
check_command check_postgres_alert_args!zulip!nagios!txn_time!20 seconds!40 seconds
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -252,7 +252,7 @@ define service {
|
|||
|
||||
define service{
|
||||
use generic-service
|
||||
service_description Check postgres replication lag
|
||||
service_description Check Postgres replication lag
|
||||
check_command check_postgres_replication_lag
|
||||
hostgroup postgres_appdb
|
||||
contact_groups admins
|
||||
|
|
@ -288,7 +288,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq queue sizes
|
||||
service_description Check RabbitMQ queue sizes
|
||||
check_command check_rabbitmq_queues!22
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -307,7 +307,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq notify_tornado consumers
|
||||
service_description Check RabbitMQ notify_tornado consumers
|
||||
check_command check_rabbitmq_consumers!notify_tornado
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -318,7 +318,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq user_activity_interval consumers
|
||||
service_description Check RabbitMQ user_activity_interval consumers
|
||||
check_command check_rabbitmq_consumers!user_activity_interval
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -329,7 +329,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq user_presence consumers
|
||||
service_description Check RabbitMQ user_presence consumers
|
||||
check_command check_rabbitmq_consumers!user_presence
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -340,7 +340,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq invites consumers
|
||||
service_description Check RabbitMQ invites consumers
|
||||
check_command check_rabbitmq_consumers!invites
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -351,7 +351,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq signups consumers
|
||||
service_description Check RabbitMQ signups consumers
|
||||
check_command check_rabbitmq_consumers!signups
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -362,7 +362,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq digest email consumers
|
||||
service_description Check RabbitMQ digest email consumers
|
||||
check_command check_rabbitmq_consumers!digest_emails
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -373,7 +373,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq email mirror consumers
|
||||
service_description Check RabbitMQ email mirror consumers
|
||||
check_command check_rabbitmq_consumers!email_mirror
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -384,7 +384,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq missedmessage mobile notifications consumers
|
||||
service_description Check RabbitMQ missedmessage mobile notifications consumers
|
||||
check_command check_rabbitmq_consumers!missedmessage_mobile_notifications
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -395,7 +395,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq missedmessage email consumers
|
||||
service_description Check RabbitMQ missedmessage email consumers
|
||||
check_command check_rabbitmq_consumers!missedmessage_email
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
@ -406,7 +406,7 @@ define service {
|
|||
|
||||
define service {
|
||||
use generic-service
|
||||
service_description Check rabbitmq user activity consumers
|
||||
service_description Check RabbitMQ user activity consumers
|
||||
check_command check_rabbitmq_consumers!user_activity
|
||||
# Workaround weird checks 40s after first error causing alerts
|
||||
# from a single failure because cron hasn't run again yet
|
||||
|
|
|
|||
|
|
@ -190,8 +190,8 @@ class zulip_ops::base {
|
|||
ensure => running,
|
||||
|
||||
# Because there is no running process for this service, the normal status
|
||||
# checks fail. Because puppet then thinks the service has been manually
|
||||
# stopped, it won't restart it. This fake status command will trick puppet
|
||||
# checks fail. Because Puppet then thinks the service has been manually
|
||||
# stopped, it won't restart it. This fake status command will trick Puppet
|
||||
# into thinking the service is *always* running (which in a way it is, as
|
||||
# iptables is part of the kernel.)
|
||||
hasstatus => true,
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ jsx-lexer
|
|||
# Needed for manage.py
|
||||
ipython
|
||||
|
||||
# Needed for Image Processing
|
||||
# Needed for image processing
|
||||
Pillow
|
||||
|
||||
# Needed for building complex DB queries
|
||||
|
|
@ -59,7 +59,7 @@ httplib2
|
|||
# Forked to avoid pulling in scipy: https://github.com/mailgun/talon/issues/130
|
||||
https://github.com/zulip/talon/archive/7d8bdc4dbcfcc5a73298747293b99fe53da55315.zip#egg=talon==1.2.10.zulip1
|
||||
|
||||
# Needed for hipchat import
|
||||
# Needed for HipChat import
|
||||
hypchat
|
||||
|
||||
# Needed for inlining the CSS in emails
|
||||
|
|
@ -71,7 +71,7 @@ PyJWT
|
|||
# Needed for including other Markdown files for user docs
|
||||
markdown-include
|
||||
|
||||
# Needed to access rabbitmq
|
||||
# Needed to access RabbitMQ
|
||||
pika
|
||||
|
||||
# Needed to access our database
|
||||
|
|
@ -89,7 +89,7 @@ python-dateutil
|
|||
# Needed for timezone work
|
||||
pytz
|
||||
|
||||
# Needed for redis
|
||||
# Needed for Redis
|
||||
redis
|
||||
|
||||
# Needed to parse source maps for error reporting
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ from scripts.lib.zulip_tools import parse_cache_script_args
|
|||
|
||||
|
||||
def main() -> None:
|
||||
args = parse_cache_script_args("This script cleans unused zulip caches.")
|
||||
args = parse_cache_script_args("This script cleans unused Zulip caches.")
|
||||
os.chdir(ZULIP_PATH)
|
||||
clean_venv_cache.main(args)
|
||||
clean_node_cache.main(args)
|
||||
|
|
|
|||
|
|
@ -43,5 +43,5 @@ def main(args: argparse.Namespace) -> None:
|
|||
EMOJI_CACHE_PATH, caches_in_use, "emoji cache", args)
|
||||
|
||||
if __name__ == "__main__":
|
||||
args = parse_cache_script_args("This script cleans unused zulip emoji caches.")
|
||||
args = parse_cache_script_args("This script cleans unused Zulip emoji caches.")
|
||||
main(args)
|
||||
|
|
|
|||
|
|
@ -46,5 +46,5 @@ def main(args: argparse.Namespace) -> None:
|
|||
NODE_MODULES_CACHE_PATH, caches_in_use, "node modules cache", args)
|
||||
|
||||
if __name__ == "__main__":
|
||||
args = parse_cache_script_args("This script cleans unused zulip npm caches.")
|
||||
args = parse_cache_script_args("This script cleans unused Zulip npm caches.")
|
||||
main(args)
|
||||
|
|
|
|||
|
|
@ -54,5 +54,5 @@ def main(args: argparse.Namespace) -> None:
|
|||
VENV_CACHE_DIR, caches_in_use, "venv cache", args)
|
||||
|
||||
if __name__ == "__main__":
|
||||
args = parse_cache_script_args("This script cleans unused zulip venv caches.")
|
||||
args = parse_cache_script_args("This script cleans unused Zulip venv caches.")
|
||||
main(args)
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ forwarding emails into Zulip.
|
|||
https://zulip.readthedocs.io/en/latest/production/settings.html#email-gateway
|
||||
|
||||
The email gateway supports two major modes of operation: An email
|
||||
server (using postfix) where the email address configured in
|
||||
server (using Postfix) where the email address configured in
|
||||
EMAIL_GATEWAY_PATTERN delivers emails directly to Zulip (this) or a
|
||||
cron job that connects to an IMAP inbox (which receives the emails)
|
||||
periodically.
|
||||
|
||||
Zulip's puppet configuration takes care of configuring postfix to
|
||||
execute this script when emails are received by postfix, piping the
|
||||
Zulip's Puppet configuration takes care of configuring Postfix to
|
||||
execute this script when emails are received by Postfix, piping the
|
||||
email content via standard input (and the destination email address in
|
||||
the ORIGINAL_RECIPIENT environment variable).
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ parser.add_argument('-d', '--dst-host', dest="host", default='https://127.0.0.1'
|
|||
"Address must contain a HTTP protocol.")
|
||||
|
||||
parser.add_argument('-u', '--dst-url', dest="url", default='/email_mirror_message',
|
||||
help="Destination relative url for uploading email from email mirror.")
|
||||
help="Destination relative URL for uploading email from email mirror.")
|
||||
|
||||
parser.add_argument('-n', '--not-verify-ssl', dest="verify_ssl", action='store_false',
|
||||
help="Disable ssl certificate verifying for self-signed certificates")
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ fi
|
|||
read -r -a APT_OPTIONS <<<"${APT_OPTIONS:-}"
|
||||
# Install additional packages.
|
||||
read -r -a ADDITIONAL_PACKAGES <<<"${ADDITIONAL_PACKAGES:-}"
|
||||
# Comma-separated list of puppet manifests to install. default is
|
||||
# Comma-separated list of Puppet manifests to install. default is
|
||||
# zulip::voyager for an all-in-one system or zulip::dockervoyager for
|
||||
# Docker. Use e.g. zulip::app_frontend for a Zulip frontend server.
|
||||
PUPPET_CLASSES="${PUPPET_CLASSES:-zulip::voyager}"
|
||||
|
|
@ -234,8 +234,8 @@ fi
|
|||
case ",$PUPPET_CLASSES," in
|
||||
*,zulip::voyager,* | *,zulip::postgres_appdb_tuned,*)
|
||||
if [ "$package_system" = apt ]; then
|
||||
# We're going to install Postgres from the postgres apt
|
||||
# repository; this may conflict with the existing postgres.
|
||||
# We're going to install Postgres from the Postgres apt
|
||||
# repository; this may conflict with the existing Postgres.
|
||||
OTHER_PG="$(dpkg --get-selections \
|
||||
| grep -E '^postgresql-[0-9]+\s+install$' \
|
||||
| grep -v "^postgresql-$POSTGRES_VERSION\b" \
|
||||
|
|
@ -405,7 +405,7 @@ EOF
|
|||
--classfile=/var/lib/puppet/classes.txt \
|
||||
>/dev/null
|
||||
|
||||
# We only need the postgres version setting on database hosts; but
|
||||
# We only need the Postgres version setting on database hosts; but
|
||||
# we don't know if this is a database host until we have the catalog summary.
|
||||
if ! has_class "zulip::postgres_common" || [ "$package_system" != apt ]; then
|
||||
crudini --del /etc/zulip/zulip.conf postgresql
|
||||
|
|
@ -511,7 +511,7 @@ if has_class "zulip::app_frontend_base"; then
|
|||
chown -R zulip:zulip /home/zulip /var/log/zulip /etc/zulip/settings.py
|
||||
|
||||
if ! [ -e "/home/zulip/prod-static/generated" ]; then
|
||||
# If we're installing from a git checkout, we need to run
|
||||
# If we're installing from a Git checkout, we need to run
|
||||
# `tools/update-prod-static` in order to build the static
|
||||
# assets.
|
||||
su zulip -c '/home/zulip/deployments/current/tools/update-prod-static'
|
||||
|
|
@ -525,7 +525,7 @@ if [ -n "$NO_INIT_DB" ]; then
|
|||
Success!
|
||||
|
||||
Stopping because --no-init-db was passed.
|
||||
To complete the installation, configure postgres and then run:
|
||||
To complete the installation, configure Postgres and then run:
|
||||
|
||||
su zulip -c '/home/zulip/deployments/current/scripts/setup/initialize-database'
|
||||
su zulip -c '/home/zulip/deployments/current/manage.py generate_realm_creation_link'
|
||||
|
|
|
|||
|
|
@ -199,19 +199,19 @@ elif args.from_git:
|
|||
logging.info("Shutting down server to build static assets on a low-RAM system.")
|
||||
shutdown_server()
|
||||
|
||||
# Note: The fact that this is before we apply puppet changes means
|
||||
# that we don't support adding new puppet dependencies of
|
||||
# update-prod-static with the git upgrade process. But it'll fail
|
||||
# Note: The fact that this is before we apply Puppet changes means
|
||||
# that we don't support adding new Puppet dependencies of
|
||||
# update-prod-static with the Git upgrade process. But it'll fail
|
||||
# safely; this seems like a worthwhile tradeoff to minimize downtime.
|
||||
logging.info("Building static assets...")
|
||||
subprocess.check_call(["./tools/update-prod-static", "--prev-deploy=" +
|
||||
os.path.join(DEPLOYMENTS_DIR, 'current')],
|
||||
preexec_fn=su_to_zulip)
|
||||
logging.info("Caching zulip git version...")
|
||||
logging.info("Caching Zulip Git version...")
|
||||
subprocess.check_call(["./tools/cache-zulip-git-version"], preexec_fn=su_to_zulip)
|
||||
else:
|
||||
# Since this doesn't do any actual work, it's likely safe to have
|
||||
# this run before we apply puppet changes (saving a bit of downtime).
|
||||
# this run before we apply Puppet changes (saving a bit of downtime).
|
||||
logging.info("Installing static assets...")
|
||||
subprocess.check_call(["cp", "-rT", os.path.join(deploy_path, 'prod-static/serve'),
|
||||
'/home/zulip/prod-static'], preexec_fn=su_to_zulip)
|
||||
|
|
@ -252,12 +252,12 @@ if os.path.exists("/etc/supervisor/conf.d/zulip_db.conf"):
|
|||
|
||||
if (not args.skip_puppet or migrations_needed) and IS_SERVER_UP:
|
||||
# By default, we shut down the service to apply migrations and
|
||||
# puppet changes, to minimize risk of issues due to inconsistent
|
||||
# Puppet changes, to minimize risk of issues due to inconsistent
|
||||
# state.
|
||||
shutdown_server()
|
||||
|
||||
if not args.skip_puppet:
|
||||
logging.info("Applying puppet changes...")
|
||||
logging.info("Applying Puppet changes...")
|
||||
subprocess.check_call(["./scripts/zulip-puppet-apply", "--force"])
|
||||
subprocess.check_call(["apt-get", "-y", "upgrade"])
|
||||
|
||||
|
|
@ -283,5 +283,5 @@ else:
|
|||
logging.info("Skipping purging old deployments.")
|
||||
|
||||
if args.skip_puppet:
|
||||
logging.info("Showing un-applied puppet changes:")
|
||||
logging.info("Showing un-applied Puppet changes:")
|
||||
subprocess.check_call(["./scripts/zulip-puppet-apply", "--noop", "--show_diff"])
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ def generate_secrets(development: bool = False) -> None:
|
|||
if settings.MEMCACHED_LOCATION == "127.0.0.1:11211":
|
||||
add_secret("memcached_password", random_token())
|
||||
|
||||
# Password for authentication to redis.
|
||||
# Password for authentication to Redis.
|
||||
if need_secret("redis_password"):
|
||||
# We defer importing settings unless we need it, because
|
||||
# importing settings is expensive (mostly because of
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ set -x
|
|||
# What user should we use for connecting to the database
|
||||
POSTGRES_USER="${POSTGRES_USER:-postgres}"
|
||||
|
||||
# This psql command may fail because the zulip database doesn’t exist,
|
||||
# This psql command may fail because the Zulip database doesn’t exist,
|
||||
# hence the &&.
|
||||
if records="$(
|
||||
cd / # Make sure the current working directory is readable by postgres
|
||||
|
|
|
|||
|
|
@ -115,10 +115,10 @@ def restore_backup(tarball_file: IO[bytes]) -> None:
|
|||
"--production",
|
||||
])
|
||||
|
||||
# If there is a local rabbitmq, we need to reconfigure it
|
||||
# to ensure the rabbitmq password matches the value in the
|
||||
# If there is a local RabbitMQ, we need to reconfigure it
|
||||
# to ensure the RabbitMQ password matches the value in the
|
||||
# restored zulip-secrets.conf. We need to be careful to
|
||||
# only do this if rabbitmq is configured to run locally on
|
||||
# only do this if RabbitMQ is configured to run locally on
|
||||
# the system.
|
||||
rabbitmq_host = subprocess.check_output(
|
||||
[os.path.join(settings.DEPLOY_ROOT,
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ if pg_lsclusters -h | grep -qE "^$UPGRADE_TO\s+main\b"; then
|
|||
fi
|
||||
|
||||
(
|
||||
# Two-stage application of puppet; we apply the bare-bones
|
||||
# postgresql configuration first, so that FTS will be configured
|
||||
# Two-stage application of Puppet; we apply the bare-bones
|
||||
# PostgreSQL configuration first, so that FTS will be configured
|
||||
# prior to the pg_upgradecluster.
|
||||
TEMP_CONF_DIR=$(mktemp -d)
|
||||
cp /etc/zulip/zulip.conf "$TEMP_CONF_DIR"
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ from lib.zulip_tools import assert_running_as_root, parse_os_release
|
|||
assert_running_as_root()
|
||||
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
|
||||
|
||||
parser = argparse.ArgumentParser(description="Run puppet")
|
||||
parser = argparse.ArgumentParser(description="Run Puppet")
|
||||
parser.add_argument('--force', '-f', action="store_true",
|
||||
help="Do not prompt with proposed changes")
|
||||
parser.add_argument('--noop', action="store_true",
|
||||
|
|
@ -32,7 +32,7 @@ Exec { path => "/usr/sbin:/usr/bin:/sbin:/bin" }
|
|||
for pclass in re.split(r'\s*,\s*', config.get('machine', 'puppet_classes')):
|
||||
puppet_config += f"include {pclass}\n"
|
||||
|
||||
# We use the puppet configuration from the same Zulip checkout as this script
|
||||
# We use the Puppet configuration from the same Zulip checkout as this script
|
||||
scripts_path = os.path.join(BASE_DIR, "scripts")
|
||||
puppet_module_path = os.path.join(BASE_DIR, "puppet")
|
||||
puppet_cmd = ["puppet", "apply", f"--modulepath={puppet_module_path}", "-e", puppet_config]
|
||||
|
|
@ -40,12 +40,12 @@ if args.noop:
|
|||
puppet_cmd += ["--noop"]
|
||||
puppet_cmd += extra_args
|
||||
|
||||
# Set the scripts path to be a factor so it can be used by puppet code
|
||||
# Set the scripts path to be a factor so it can be used by Puppet code
|
||||
puppet_env = os.environ.copy()
|
||||
puppet_env["FACTER_zulip_conf_path"] = args.config
|
||||
puppet_env["FACTER_zulip_scripts_path"] = scripts_path
|
||||
|
||||
# This is to suppress puppet warnings with ruby 2.7.
|
||||
# This is to suppress Puppet warnings with ruby 2.7.
|
||||
if (distro_info['ID'], distro_info['VERSION_ID']) in [('ubuntu', '20.04')]:
|
||||
puppet_env["RUBYOPT"] = "-W0"
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ about Noto, please refer to:
|
|||
|
||||
https://code.google.com/p/noto/
|
||||
|
||||
These images were generated from the git repository at
|
||||
These images were generated from the Git repository at
|
||||
<https://android.googlesource.com/platform/external/noto-fonts> as of
|
||||
90372d894b5d9c9f2a111315d2eb3b8de1979ee4
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
import "./common";
|
||||
|
||||
// Import Third party libraries
|
||||
// Import third party libraries
|
||||
import "../../third/bootstrap-notify/js/bootstrap-notify";
|
||||
import "../../third/bootstrap-typeahead/typeahead";
|
||||
import "../../third/bootstrap-tooltip/tooltip";
|
||||
|
|
@ -12,7 +12,7 @@ import "jquery-validation";
|
|||
import "flatpickr";
|
||||
import "flatpickr/dist/plugins/confirmDate/confirmDate";
|
||||
|
||||
// Import App JS
|
||||
// Import app JS
|
||||
import "../i18n";
|
||||
import "../feature_flags";
|
||||
import "../loading";
|
||||
|
|
@ -195,7 +195,7 @@ import "../search_pill_widget";
|
|||
import "../stream_ui_updates";
|
||||
import "../spoilers";
|
||||
|
||||
// Import Styles
|
||||
// Import styles
|
||||
|
||||
import "../../third/bootstrap-notify/css/bootstrap-notify.css";
|
||||
import "spectrum-colorpicker/spectrum.css";
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ exports.compute_placeholder_text = function (opts) {
|
|||
}
|
||||
}
|
||||
|
||||
// For Private Messages
|
||||
// For private messages
|
||||
if (opts.private_message_recipient) {
|
||||
const recipient_list = opts.private_message_recipient.split(",");
|
||||
const recipient_names = recipient_list
|
||||
|
|
|
|||
|
|
@ -59,12 +59,12 @@ exports.encode_stream_name = function (operand) {
|
|||
|
||||
exports.decodeHashComponent = function (str) {
|
||||
try {
|
||||
// This fails for URLS containing
|
||||
// This fails for URLs containing
|
||||
// foo.foo or foo%foo due to our fault in special handling
|
||||
// of such characters when encoding. This can also,
|
||||
// fail independent of our fault, so just tell the user
|
||||
// that the url is invalid.
|
||||
// TODO: Show possible valid urls to the user.
|
||||
// that the URL is invalid.
|
||||
// TODO: Show possible valid URLs to the user.
|
||||
return decodeURIComponent(str.replace(/\./g, "%"));
|
||||
} catch {
|
||||
ui_report.error(i18n.t("Invalid URL"), undefined, $("#home-error"), 2000);
|
||||
|
|
|
|||
|
|
@ -231,7 +231,7 @@ exports.add_topic_links = function (message) {
|
|||
}
|
||||
}
|
||||
|
||||
// Also make raw urls navigable
|
||||
// Also make raw URLs navigable
|
||||
const url_re = /\b(https?:\/\/[^\s<]+[^\s"'),.:;<\]])/g; // Slightly modified from third/marked.js
|
||||
const match = topic.match(url_re);
|
||||
if (match) {
|
||||
|
|
@ -268,11 +268,11 @@ function handleEmoji(emoji_name) {
|
|||
const alt_text = ":" + emoji_name + ":";
|
||||
const title = emoji_name.split("_").join(" ");
|
||||
|
||||
// Zulip supports both standard/unicode emoji, served by a
|
||||
// Zulip supports both standard/Unicode emoji, served by a
|
||||
// spritesheet and custom realm-specific emoji (served by URL).
|
||||
// We first check if this is a realm emoji, and if so, render it.
|
||||
//
|
||||
// Otherwise we'll look at unicode emoji to render with an emoji
|
||||
// Otherwise we'll look at Unicode emoji to render with an emoji
|
||||
// span using the spritesheet; and if it isn't one of those
|
||||
// either, we pass through the plain text syntax unmodified.
|
||||
const emoji_url = emoji.get_realm_emoji_url(emoji_name);
|
||||
|
|
@ -381,7 +381,7 @@ function python_to_js_filter(pattern, url) {
|
|||
const name = match[1];
|
||||
// Replace named group with regular matching group
|
||||
pattern = pattern.replace("(?P<" + name + ">", "(");
|
||||
// Replace named reference in url to numbered reference
|
||||
// Replace named reference in URL to numbered reference
|
||||
url = url.replace("%(" + name + ")s", "\\" + current_group);
|
||||
|
||||
// Reset the RegExp state
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue