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

84 lines
2.5 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 .
circleci: Set up locale en_US.UTF-8. See comment for motivation and what's known. [greg: Added comment, summarizing Vishnu's results from testing.]
2017-12-13 20:52:16 +01:00
- image: gregprice/circleci:trusty-python-3.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.
circleci: Remove Circle-created gitconfig file. [Investigation by hackerkid.]
2017-09-20 02:36:30 +02:00
# CircleCI sets the following in Git config at clone time:
# url.ssh://git@github.com.insteadOf https://github.com
# This breaks the Git clones in the NVM `install.sh` we run
# in `install-node`.
# TODO: figure out why that breaks, and whether we want it.
# (Is it an optimization?)
rm -f /home/circleci/.gitconfig
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
# 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
circleci: Run frontend tests in circleci.
2018-01-05 12:11:11 +01:00
# The moment of truth! Run the tests.
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
- run:
circleci: Run frontend tests in circleci.
2018-01-05 12:11:11 +01:00
name: run backend tests
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
command: |
. /srv/zulip-py3-venv/bin/activate
mispipe ./tools/travis/backend ts
circleci: Run frontend tests in circleci.
2018-01-05 12:11:11 +01:00
- run:
name: run frontend tests
command: |
. /srv/zulip-py3-venv/bin/activate
mispipe ./tools/travis/frontend ts
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
# - store_artifacts: # TODO
# path: var/casper/
# # also /tmp/zulip-test-event-log/
# destination: test-reports
# TODO: notify zulipbot