Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/tools/travis/production-helper

34 lines
1.4 KiB
Plaintext
Raw Normal View History

Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work.
2015-10-15 01:47:42 +02:00
#!/bin/bash
set -e
set -x
travis: Fix prompting for user input in production-helper.
2015-12-08 05:31:53 +01:00
apt-get install -y openssl ssl-cert
Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work.
2015-10-15 01:47:42 +02:00
ln -s /etc/ssl/certs/ssl-cert-snakeoil.pem /etc/ssl/certs/zulip.combined-chain.crt
ln -s /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/private/zulip.key
tar -xf zulip-server-travis.tar.gz
mv zulip-server-travis /root/zulip
Fix postgres errors in Travis CI again. Travis CI's model of installing every version of postgres on the test VM and then shutting all the versions other than the one requested down seems to not work very well with doing apt upgrades. It seems the best way to resolve this is to just uninstall the versions we don't need.
2016-01-19 20:44:21 +01:00
# Do an apt upgrade to start with an up-to-date machine
Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work.
2015-10-15 01:47:42 +02:00
export APT_OPTIONS="-o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold"
travis: Do an apt-get update before the apt upgrade. This should save several minutes off the Travis CI `production` suite's runtime, since previously we were doing the full apt upgrade process twice, resulting in things like multiple expensive rebuilds of the initramfs.
2016-05-02 23:34:49 +02:00
apt-get update
travis: hold expensive to upgrade packages in Travis CI. This should save a few minutes of time running the production test suite. This is part of solving #722.
2016-05-02 23:45:44 +02:00
# Hold upgrades to packages which are expensive to upgrade due to size
# or computational cost (e.g. initramfs rebuilds) and aren't really
# used by Zulip in production.
apt-mark hold initramfs-tools initramfs-tools-bin oracle-java8-installer udev linux-image-3.19.0-28-generic linux-image-generic-lts-vivid base-files linux-firmware chromium-browser google-chrome-stable g++-4.8 gcc-4.8 cpp-4.8 openjdk-6-jre-headless openjdk-7-jre-headless
travis: Workaround postgres 9.1 conflict issues on trusty. We ran into a bug with the Travis CI infrastructure where it postgres 9.1 is installed on the system, and so when we'd do an apt upgrade with a new version of 9.1, the 9.1 daemon would end up getting started and conflict with the 9.3 daemon we were trying to run.
2016-01-10 00:13:12 +01:00
apt-get upgrade -y $APT_OPTIONS
# Install Zulip
Run a local camo server in voyager production environments. Camo is a caching image proxy, used in Zulip to avoid mixed-content warnings by proxying HTTP image content over HTTPS. We've been using it in zulip.com production for years; this change makes it available in standalone Zulip deployments.
2016-04-28 07:32:27 +02:00
env TRAVIS=1 /root/zulip/scripts/setup/install
Expand testing done via Travis CI to cover production pipeline. With this change, we are now testing the production static asset pipeline and installation process in a new testing job (and also run the frontend/backend tests separately). This means that changes that break the Zulip static asset pipeline or production installation process are more likely to fail tests. The testing is imperfect in that it does not have proper isolation -- we build a complete Zulip development environment and then install a Zulip production environment on top of it, so e.g. any apt dependencies installed for Zulip development will still be available for the Zulip production environment. But, it's better than nothing! A good v2 of this would be to have the production setup process just install the minimum stuff needed to run `build-release-tarball` and then uninstall it / clean it up so that we can do a more clear production installation, but that's more work.
2015-10-15 01:47:42 +02:00
cat >>/etc/zulip/settings.py <<EOF
# Travis CI override settings above
EXTERNAL_HOST = 'zulip.travis.example.com'
ZULIP_ADMINISTRATOR = 'zulip-travis-admin@travis.example.com'
ADMIN_DOMAIN = 'travis.example.com'
AUTHENTICATION_BACKENDS = ( 'zproject.backends.EmailAuthBackend', )
NOREPLY_EMAIL_ADDRESS = 'noreply@travis.example.com'
DEFAULT_FROM_EMAIL = "Zulip <zulip@travis.example.com>"
EOF
su zulip -c /home/zulip/deployments/current/scripts/setup/initialize-database