Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/.circleci/config.yml

71 lines
2.0 KiB
YAML
Raw Normal View History

circle: Draft a config for running our builds in CircleCI. From just my experience attempting this change, I've been impressed with the very fast turnaround in CircleCI for a change -- from `git push` to the build starting is usually just a couple of seconds. It also looks like we get much clearer control over the caching system, and the setup of the environment via a Docker image of our choice, which can help avoid most of the several minutes Travis takes to set up our environment before it actually starts running the tests themselves. Plus it supports fine-grained parallelism, e.g. by test file: https://circleci.com/docs/2.0/parallelism-faster-jobs/ So we can probably get much faster builds by making this switch. Because the environment is much more transparent and even under our control, I'm also hopeful for more reliable builds.
2017-08-30 02:09:09 +02:00
# See CircleCI upstream's docs on this config format:
# https://circleci.com/docs/2.0/language-python/
#
version: 2
jobs:
build:
docker:
# This is built from tools/circleci/images/Dockerfile .
circle: Bump base image version. This new base image just comes from me doing a fresh `docker build` and uploading the result. That gives it fresher versions of our APT dependencies than the image I built a couple of months ago, speeding up provision by giving it less to install.
2017-12-02 01:31:29 +01:00
- image: gregprice/circleci:trusty-python-2.test
circle: Draft a config for running our builds in CircleCI. From just my experience attempting this change, I've been impressed with the very fast turnaround in CircleCI for a change -- from `git push` to the build starting is usually just a couple of seconds. It also looks like we get much clearer control over the caching system, and the setup of the environment via a Docker image of our choice, which can help avoid most of the several minutes Travis takes to set up our environment before it actually starts running the tests themselves. Plus it supports fine-grained parallelism, e.g. by test file: https://circleci.com/docs/2.0/parallelism-faster-jobs/ So we can probably get much faster builds by making this switch. Because the environment is much more transparent and even under our control, I'm also hopeful for more reliable builds.
2017-08-30 02:09:09 +02:00
working_directory: ~/repo
steps:
- checkout
- run:
name: create cache directories
command: |
dirs=(/srv/zulip-{npm,venv}-cache)
sudo mkdir -p "${dirs[@]}"
sudo chown -R circleci "${dirs[@]}"
- restore_cache:
keys:
circle: Bump cache version. This will store a fresh version of the cached trees to the new ...-base2 keys, and then the *next* build will use those instead of the ...-base1 keys.
2017-12-02 00:56:07 +01:00
- v1-node-base2
circle: Draft a config for running our builds in CircleCI. From just my experience attempting this change, I've been impressed with the very fast turnaround in CircleCI for a change -- from `git push` to the build starting is usually just a couple of seconds. It also looks like we get much clearer control over the caching system, and the setup of the environment via a Docker image of our choice, which can help avoid most of the several minutes Travis takes to set up our environment before it actually starts running the tests themselves. Plus it supports fine-grained parallelism, e.g. by test file: https://circleci.com/docs/2.0/parallelism-faster-jobs/ So we can probably get much faster builds by making this switch. Because the environment is much more transparent and even under our control, I'm also hopeful for more reliable builds.
2017-08-30 02:09:09 +02:00
- v1-node-base1
- restore_cache:
keys:
circle: Bump cache version. This will store a fresh version of the cached trees to the new ...-base2 keys, and then the *next* build will use those instead of the ...-base1 keys.
2017-12-02 00:56:07 +01:00
- v1-venv-base2
circle: Draft a config for running our builds in CircleCI. From just my experience attempting this change, I've been impressed with the very fast turnaround in CircleCI for a change -- from `git push` to the build starting is usually just a couple of seconds. It also looks like we get much clearer control over the caching system, and the setup of the environment via a Docker image of our choice, which can help avoid most of the several minutes Travis takes to set up our environment before it actually starts running the tests themselves. Plus it supports fine-grained parallelism, e.g. by test file: https://circleci.com/docs/2.0/parallelism-faster-jobs/ So we can probably get much faster builds by making this switch. Because the environment is much more transparent and even under our control, I'm also hopeful for more reliable builds.
2017-08-30 02:09:09 +02:00
- v1-venv-base1
- run:
name: install dependencies
command: |
# Install moreutils so we can use `ts` and `mispipe` in the following.
sudo apt-get install -y moreutils
# TODO: Install and use codecov.
# This is the main setup job for the test suite
mispipe "tools/travis/setup-backend" ts
# Cleaning caches is mostly unnecessary in Circle, because
# most builds don't get to write to the cache.
# mispipe "scripts/lib/clean-unused-caches --verbose --threshold 0" ts
- save_cache:
paths:
- /srv/zulip-npm-cache
circle: Bump cache version. This will store a fresh version of the cached trees to the new ...-base2 keys, and then the *next* build will use those instead of the ...-base1 keys.
2017-12-02 00:56:07 +01:00
key: v1-node-base2
circle: Draft a config for running our builds in CircleCI. From just my experience attempting this change, I've been impressed with the very fast turnaround in CircleCI for a change -- from `git push` to the build starting is usually just a couple of seconds. It also looks like we get much clearer control over the caching system, and the setup of the environment via a Docker image of our choice, which can help avoid most of the several minutes Travis takes to set up our environment before it actually starts running the tests themselves. Plus it supports fine-grained parallelism, e.g. by test file: https://circleci.com/docs/2.0/parallelism-faster-jobs/ So we can probably get much faster builds by making this switch. Because the environment is much more transparent and even under our control, I'm also hopeful for more reliable builds.
2017-08-30 02:09:09 +02:00
- save_cache:
paths:
- /srv/zulip-venv-cache
circle: Bump cache version. This will store a fresh version of the cached trees to the new ...-base2 keys, and then the *next* build will use those instead of the ...-base1 keys.
2017-12-02 00:56:07 +01:00
key: v1-venv-base2
circle: Draft a config for running our builds in CircleCI. From just my experience attempting this change, I've been impressed with the very fast turnaround in CircleCI for a change -- from `git push` to the build starting is usually just a couple of seconds. It also looks like we get much clearer control over the caching system, and the setup of the environment via a Docker image of our choice, which can help avoid most of the several minutes Travis takes to set up our environment before it actually starts running the tests themselves. Plus it supports fine-grained parallelism, e.g. by test file: https://circleci.com/docs/2.0/parallelism-faster-jobs/ So we can probably get much faster builds by making this switch. Because the environment is much more transparent and even under our control, I'm also hopeful for more reliable builds.
2017-08-30 02:09:09 +02:00
# TODO: in Travis we also cache ~/zulip-emoji-cache, ~/node, ~/misc
# The moment of truth!
# TODO: add frontend suite; prod suite; and backend on Python 3.5
# TODO: add parallelism; see https://circleci.com/docs/2.0/workflows/
- run:
name: run tests
command: |
. /srv/zulip-py3-venv/bin/activate
mispipe ./tools/travis/backend ts
# - store_artifacts: # TODO
# path: var/casper/
# # also /tmp/zulip-test-event-log/
# destination: test-reports
# TODO: notify zulipbot