zulip · arpit551 · Apr 26, 2020 · Apr 28, 2020 · Apr 28, 2020 · arpit551
diff --git a/docs/contributing/code-reviewing.md b/docs/contributing/code-reviewing.md
@@ -72,8 +72,8 @@ this?". Good choices include
   to the commit hash or the Detail links on a pull request. (Example:
   in [#10618](https://github.com/zulip/zulip/pull/10618), browse to
   bottom and click the red X next to `c6044ee` to see the build jobs
-  for that commit. You can see that there are 4 build jobs in total.
-  3 are by CircleCI and 1 is by Travis CI. You can see what caused
+  for that commit. You can see that there are 5 build jobs in total.
+  All the 5 jobs run in Circle CI. You can see what caused
   the job to fail by clicking on the failed job. This will open
   up a page in the CI that has more details on why the job failed.
   For example [this](https://circleci.com/gh/zulip/zulip/16617)

diff --git a/docs/contributing/zulipbot-usage.md b/docs/contributing/zulipbot-usage.md
@@ -85,12 +85,6 @@ assignee(s) if they are still working on the issue.
     issue's current assignee(s) and the "in progress" label to allow others to
     work on an inactive issue.
 
-* **Receive Travis build status notifications** — If you would like to receive
-a notification whenever the build status of your pull request is updated, label
-your pull request with the "travis updates" label using the command `@zulipbot
-label "travis updates"`, and **@zulipbot** will let you know the build status
-(e.g. passed, failed, errored) of your pull request once all tests finish.
-
 ### Contributing
 
 If you wish to help develop and contribute to **@zulipbot**, check out the

diff --git a/docs/git/cloning.md b/docs/git/cloning.md
@@ -104,14 +104,13 @@ first-time contributors][zulip-rtd-dev-first-time].
 This step is optional, but recommended.
 
 The Zulip Server project is configured to use [Circle CI][circle-ci]
-and [Travis CI][travis-ci] to test and create builds upon each new commit
-and pull request. CircleCI is the primary CI that runs frontend and backend
-tests across a wide range of Ubuntu distributions. Travis CI is used only for
-running the end-to-end production installer test.
-
-CircleCI and Travis CI are free for open source projects and it's easy to
-configure for your own fork of Zulip. After doing so, CircleCI and Travis
-CI will run tests for new refs you push to GitHub and email you the outcome
+to test and create builds upon each new commit and pull request.
+CircleCI is the primary CI that runs frontend and backend
+tests across a wide range of Ubuntu distributions.
+
+CircleCI is free for open source projects and it's easy to
+configure for your own fork of Zulip. After doing so, CircleCI
+will run tests for new refs you push to GitHub and email you the outcome
 (you can also view the results in the web interface).
 
 Running CI against your fork can help save both your and the
@@ -120,8 +119,8 @@ submitting a pull request.  We generally recommend a workflow where as
 you make changes, you use a fast edit-refresh cycle running individual
 tests locally until your changes work.  But then once you've gotten
 the tests you'd expect to be relevant to your changes working, push a
-branch to run the full test suite in CircleCI and Travis CI before
-you create a pull request.  While you wait for CircleCI and Travis CI
+branch to run the full test suite in CircleCI before
+you create a pull request.  While you wait for Circle CI jobs
 to run, you can start working on your next task.  When the tests finish,
 you can create a pull request that you already know passes the tests.
 
@@ -133,25 +132,14 @@ in click on **Add Projects** in right sidebar. This will list all your GitHub
 repositories. Now goto the row of Zulip and click on **Set Up Project**.
 ![Screencast of CircleCI setup](../images/zulip-circleci.gif)
 
-### Setup Travis CI
-
-First, sign in to [Travis CI][travis-ci] with your GitHub account and authorize
-Travis CI to access your GitHub account and repositories. Once you've done
-this, Travis CI will fetch your repository information and display it on your
-[profile page][travis-ci-profile]. From there you can enable integration with
-Zulip.
-![Screencast of Travis CI setup](../_static/zulip-travisci.gif)
-
 [gitbook-rebase]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
 [github-help-add-ssh-key]: https://help.github.com/en/articles/adding-a-new-ssh-key-to-your-github-account
 [github-help-conf-remote]: https://help.github.com/en/articles/configuring-a-remote-for-a-fork
 [github-help-fork]: https://help.github.com/en/articles/fork-a-repo
 [github-help-sync-fork]: https://help.github.com/en/articles/syncing-a-fork
 [github-zulip]: https://github.com/zulip/
 [github-zulip-zulip]: https://github.com/zulip/zulip/
-[travis-ci]: https://travis-ci.org/
 [circle-ci]:https://circleci.com/
-[travis-ci-profile]: https://travis-ci.org/profile
 [zulip-rtd-dev-first-time]: ../development/setup-vagrant.md
 [zulip-rtd-dev-overview]: ../development/overview.md
 [zulip-rtd-tools-setup]: ../git/zulip-tools.html#set-up-git-repo-script
diff --git a/docs/git/using.md b/docs/git/using.md
@@ -125,7 +125,7 @@ Now you're ready to work on the issue or feature.
 
 ## Run linters and tests locally
 
-In addition to having Travis run tests and linters each time you push a new
+In addition to having Circle CI run tests and linters each time you push a new
 commit, you can also run them locally. See [testing](../testing/testing.md) for details.
 
 ## Stage changes

diff --git a/docs/testing/continuous-integration.md b/docs/testing/continuous-integration.md
@@ -1,12 +1,9 @@
 # Continuous integration (CI)
 
-The Zulip server uses [CircleCI](https://circleci.com/) and
-[Travis CI](https://travis-ci.org/) for continuous
-integration. CircleCI is the primary CI, and runs frontend and backend
-tests across a wide range of Ubuntu distributions. Travis CI is
-legacy, used only for running the end-to-end production installer
-test.  This page documents useful tools and tips to know about when
-using CircleCI and Travis CI and debugging issues with them.
+The Zulip server uses [CircleCI](https://circleci.com/) for continuous
+integration. CircleCI  runs frontend, backend and end-to-end production
+installer tests. This page documents useful tools and tips to know about
+when using CircleCI and debugging issues with it.
 
 ## Goals
 
@@ -30,7 +27,7 @@ run to iteratively debug something.
 ### Useful debugging tips and tools
 
 * Zulip uses the `ts` tool to log the current time on every line of the output in
-our Travis CI scripts.  You can use this output to determine which steps are
+our Circle CI scripts.  You can use this output to determine which steps are
 actually consuming a lot of time.
 
 * You can [sign up your personal repo for CircleCI][circleci-setup] so
@@ -52,16 +49,36 @@ uses those SSH keys for authentication.
 
 The main CircleCI configuration file is
 [./circleci/config.yml](https://github.com/zulip/zulip/blob/master/.circleci/config.yml).
-We run multiple jobs during a CircleCI build to test different
-supported platforms. They are currently:
+We run multiple jobs during a CircleCI build to test both development and production environment
+in different supported platforms. They are currently:
 
+For development -
 * bionic-backend-python3.6
+* focal-backend-python3.8
 
 Each runs the Zulip backend test suites, using the indicated
 platform/OS and Python version.  As suggested by the names, only one
 suite runs the frontend test suites, since those are not
 platform-dependent.
 
+For production -
+* bionic-production-build-python3.6
+* bionic-production-install-python3.6
+
+Currently we test our production suite on Ubuntu Bionic 18.04.
+To carry out this process we use the two jobs stated above. Job
+bionic-production-build-python3.6 builts the release tarball and
+once this job finishes the tarball is then used by our downstream
+job bionic-production-install-python3.6 for installation of the production suite.
+
+We use a few helper scripts to setup the production suites:
+
+* `tools/ci/setup-production`: This script builts the release
+   tarball for the production suite.
+* `tools/ci/production-extract-tarball`: Extract the tarball for
+  production suites.
+* `tools/ci/production`: It installs and run production tests.
+
 ### Configuration
 
 The remaining details in this section are primarily relevant for doing
@@ -120,85 +137,3 @@ A consequence of this caching is that test jobs for branches which
 modify `package.json`, `requirements/`, and other key dependencies
 will be significantly slower than normal, because they won't get to
 benefit from the cache.
-
-## Travis CI
-
-### Configuration
-
-The main Travis configuration file is
-[.travis.yml](https://github.com/zulip/zulip/blob/master/.travis.yml).
-The specific test suites we have are listed in the `matrix` section,
-which has a matrix of Python versions and test suites (`$TEST_SUITE`).
-
-Currently there is only the production test suite in this section as we
-have moved the backend and frontend suite to CircleCI. So the value of
-the variable `$TEST_SUITE` would be always `production`.
-
-We've configured it to use a few helper scripts for each job:
-
-* `tools/ci/setup-$TEST_SUITE`: This script sets up the test
-  environment for the production suite. This is a complicated process
-  because of all the packages Travis installs.  See the comments in
-  `tools/ci/setup-production` for details.
-* `tools/ci/$TEST_SUITE`: The script that runs the actual test
-  production test suite.
-
-The main purpose of the distinction between the two is that if the
-`setup-production` job fails, Travis CI will report it as the suite
-having "Errored" (grey in their emails), whereas if the `production` job
-fails, it'll be reported as "Failed" failure (red in their emails).
-Note that Travis CI's web UI seems to make no visual distinction
-between these.
-
-An important detail is that Travis CI will by default hide most phases
-other than the actual test; you can see this easily by looking at the
-line numbers in the Travis CI output.  There are actually a bunch of
-phases (e.g. the project's setup job, downloading caches near the
-beginning, uploading caches at the end, etc.), and if you're debugging
-our configuration, you'll want to look at these closely.
-
-### Useful debugging tips and tools
-
-* Zulip uses the `ts` tool to log the current time on every line of
-  the output in our Travis CI scripts.  You can use this output to
-  determine which steps are actually consuming a lot of time.
-
-* For performance issues,
-  [this statistics tool](https://scribu.github.io/travis-stats/#zulip/zulip/master)
-  can give you test runtime history data that can help with
-  determining when a performance issue was introduced and whether it
-  was fixed.  Note you need to click the "Run" button for it to do
-  anything.
-
-* You can [sign up your personal repo for Travis CI][travis-fork] so
-  that every remote branch you push will be tested, which can be
-  helpful when debugging something complicated.
-
-[travis-fork]: ../git/cloning.html#step-3-configure-continuous-integration-for-your-fork
-
-### Performance optimizations
-
-#### Caching
-
-We cache the following as well apart from what is mentioned in CircleCI
-caching section.
-
-* Built/downloaded emoji sprite sheets and data.
-
-This is probably worth eventually adding to the CircleCI caches, but
-because it only saves ~5s, it hasn't been a priority yet.
-
-#### Uninstalling packages
-
-In the production suite, we run `apt-get upgrade` at some point
-(effectively, because the Zulip installer does).  This carries a huge
-performance cost in Travis CI, because (1) they don't keep their test
-systems up to date and (2) literally everything is installed in their
-build workers (e.g. several copies of Postgres, Java, MySQL, etc.).
-
-In order to make Zulip's tests performance reasonably well, we
-uninstall (or mark with `apt-mark hold`) many of these dependencies
-that are irrelevant to Zulip in
-[`tools/ci/setup-production`][setup-production].
-
-[setup-production]: https://github.com/zulip/zulip/blob/master/tools/ci/setup-production
diff --git a/docs/testing/linters.md b/docs/testing/linters.md
@@ -48,7 +48,7 @@ note are:
 * `--skip` and `--only`: Only run certain linters.
 * `-m`: Only check modified files.
 
-Finally, you can rely on our Travis CI setup to run linters for you, but
+Finally, you can rely on our Circle CI setup to run linters for you, but
 it is good practice to run lint checks locally.
 
 ```eval_rst

diff --git a/scripts/lib/clean_emoji_cache.py b/scripts/lib/clean_emoji_cache.py
@@ -13,8 +13,6 @@
 
 ENV = get_environment()
 EMOJI_CACHE_PATH = "/srv/zulip-emoji-cache"
-if ENV == "travis":
-    EMOJI_CACHE_PATH = os.path.join(os.environ["HOME"], "zulip-emoji-cache")
 
 def get_caches_in_use(threshold_days: int) -> Set[str]:
     setups_to_check = {ZULIP_PATH}

diff --git a/scripts/lib/clean_node_cache.py b/scripts/lib/clean_node_cache.py
@@ -1,7 +1,6 @@
 #!/usr/bin/env python3
 import argparse
 import os
-import subprocess
 import sys
 
 from typing import Set
@@ -14,14 +13,6 @@
 
 ENV = get_environment()
 NODE_MODULES_CACHE_PATH = "/srv/zulip-npm-cache"
-if ENV == "travis":
-    NODE_MODULES_CACHE_PATH = os.path.join(os.environ["HOME"], "zulip-npm-cache")
-    try:
-        subprocess.check_output(["/home/travis/zulip-yarn/bin/yarn", '--version'])
-    except OSError:
-        print('yarn not found. Most probably we are running static-analysis and '
-              'hence yarn is not installed. Exiting without cleaning npm cache.')
-        sys.exit(0)
 
 def get_caches_in_use(threshold_days: int) -> Set[str]:
     setups_to_check = {ZULIP_PATH}

diff --git a/scripts/lib/clean_venv_cache.py b/scripts/lib/clean_venv_cache.py
@@ -15,8 +15,6 @@
 
 ENV = get_environment()
 VENV_CACHE_DIR = '/srv/zulip-venv-cache'
-if ENV == "travis":
-    VENV_CACHE_DIR = os.path.join(os.environ["HOME"], "zulip-venv-cache")
 
 def get_caches_in_use(threshold_days: int) -> Set[str]:
     setups_to_check = {ZULIP_PATH}

diff --git a/scripts/lib/install-node b/scripts/lib/install-node
@@ -3,9 +3,6 @@ set -eo pipefail
 
 ZULIP_PATH="$(dirname "$0")/../.."
 ZULIP_SRV="/srv"
-if [ "$TRAVIS" ] ; then
-    ZULIP_SRV="/home/travis"
-fi
 YARN_PACKAGE_JSON="$ZULIP_SRV/zulip-yarn/package.json"
 node_version=12.16.1
 yarn_version=1.22.4

diff --git a/scripts/lib/node_cache.py b/scripts/lib/node_cache.py
@@ -9,11 +9,6 @@
 ZULIP_PATH = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
 ZULIP_SRV_PATH = "/srv"
 
-if 'TRAVIS' in os.environ:
-    # In Travis CI, we don't have root access
-    ZULIP_SRV_PATH = "/home/travis"
-
-
 NODE_MODULES_CACHE_PATH = os.path.join(ZULIP_SRV_PATH, 'zulip-npm-cache')
 YARN_BIN = os.path.join(ZULIP_SRV_PATH, 'zulip-yarn/bin/yarn')
 YARN_PACKAGE_JSON = os.path.join(ZULIP_SRV_PATH, 'zulip-yarn/package.json')

diff --git a/scripts/lib/setup_venv.py b/scripts/lib/setup_venv.py
@@ -10,10 +10,6 @@
 ZULIP_PATH = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
 VENV_CACHE_PATH = "/srv/zulip-venv-cache"
 
-if 'TRAVIS' in os.environ:
-    # In Travis CI, we don't have root access
-    VENV_CACHE_PATH = "/home/travis/zulip-venv-cache"
-
 VENV_DEPENDENCIES = [
     "build-essential",
     "libffi-dev",

diff --git a/scripts/lib/zulip_tools.py b/scripts/lib/zulip_tools.py
@@ -214,8 +214,6 @@ def log_management_command(cmd: str, log_path: str) -> None:
 def get_environment() -> str:
     if os.path.exists(DEPLOYMENTS_DIR):
         return "prod"
-    if os.environ.get("TRAVIS"):
-        return "travis"
     return "dev"
 
 def get_recent_deployments(threshold_days: int) -> Set[str]:

diff --git a/tools/commit-message-lint b/tools/commit-message-lint
@@ -1,14 +1,11 @@
 #!/usr/bin/env bash
 
 # Lint all commit messages that are newer than upstream/master if running
-# locally or the commits in the push or PR if in Travis CI.
+# locally or the commits in the push or PR if in Circle CI.
 
 # The rules can be found in /.gitlint
 
-if [ "$TRAVIS" ]; then
-    # Work around https://github.com/travis-ci/travis-ci/issues/4596
-    range="${TRAVIS_COMMIT_RANGE/.../..}"
-elif [[ "
+if [[ "
 $(git remote -v)
 " =~ '
 '([^[:space:]]*)[[:space:]]*(https://github\.com/|ssh://git@github\.com/|git@github\.com:)zulip/zulip(\.git|/)?\ \(fetch\)'

diff --git a/tools/lib/provision.py b/tools/lib/provision.py
@@ -29,7 +29,6 @@
 
 VAR_DIR_PATH = os.path.join(ZULIP_PATH, 'var')
 
-is_travis = 'TRAVIS' in os.environ
 is_circleci = 'CIRCLECI' in os.environ
 
 if not os.path.exists(os.path.join(ZULIP_PATH, ".git")):

diff --git a/tools/setup/emoji/build_emoji b/tools/setup/emoji/build_emoji
@@ -72,10 +72,6 @@ EMOJI_POS_INFO_TEMPLATE = """\
 # change directory
 os.chdir(EMOJI_SCRIPT_DIR_PATH)
 
-if 'TRAVIS' in os.environ:
-    # In Travis CI, we don't have root access
-    EMOJI_CACHE_PATH = "/home/travis/zulip-emoji-cache"
-
 def main() -> None:
     if not os.access(EMOJI_CACHE_PATH, os.W_OK):
         # Note: In production, this block will fail, since we don't

diff --git a/tools/test-locked-requirements b/tools/test-locked-requirements
@@ -16,8 +16,6 @@ TOOLS_DIR = os.path.abspath(os.path.dirname(__file__))
 ZULIP_PATH = os.path.dirname(TOOLS_DIR)
 REQS_DIR = os.path.join(ZULIP_PATH, 'requirements')
 CACHE_DIR = os.path.join(ZULIP_PATH, 'var', 'tmp')
-if 'TRAVIS' in os.environ:
-    CACHE_DIR = os.path.join(os.environ['HOME'], 'misc')
 CACHE_FILE = os.path.join(CACHE_DIR, 'requirements_hashes')
 
 def print_diff(path_file1: str, path_file2: str) -> None: