Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/tools/ci/setup-backend

19 lines
628 B
Plaintext
Raw Normal View History

Use #!/usr/bin/env for bash shebangs. /bin/sh and /usr/bin/env are the only two binaries that NixOS provides at a fixed path (outside a buildFHSUserEnv sandbox). This discussion was split from #11004. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
2018-12-18 02:08:53 +01:00
#!/usr/bin/env bash
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
set -e
set -x
Add wrapper and log file output for provisioning. Before this commit, provisioning was done by executing provision.py, which printed the log directly to stdout, making debugging harder. This commit creates a wrapper bash script 'provision' in tools, which calls 'zulip/scripts/tools/provision_vm.py' (the new location of provision.py) and prints all the output to 'zulip/var/log/zulip/zulip_provision.log' via 'tee'. Travis tests and docs have been modified accordingly.
2017-01-14 11:19:26 +01:00
docs: Add a bunch of documentation on Travis CI.
2017-06-06 03:15:17 +02:00
# This is just a thin wrapper around provision.
setup-backend: Add wrapper to retry provisioning in case it fails. In this commit we add a wrapper around the provisioning inside setup-backend to trigger another try at provisioning if it fails in hopes of it will run this time fine if it was interuppted by a network issue the first time. Fixes: #2034.
2017-06-13 22:00:11 +02:00
# Provisioning may fail due to many issues but most of the times a network
# connection issue is the reason. So we are going to retry entire provisioning
# once again if that fixes our problem.
ci: Remove 2>&1 redirection. We had used 2>&1 to redirect stderr to stdout so it could be piped into ts, but commit dd3cdd6ec5085c25b6a9491b7e9b672ae99af442 (#17611) removed ts, so we no longer need the redirection. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-03-29 20:51:40 +02:00
tools/provision "$@" || {
install, provision: Treat all nonzero exit codes as failure, not just 1. Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2019-07-19 03:36:59 +02:00
ret=$?
if [ "$ret" = 1 ]; then
echo "\`provision\`: Something went wrong with the provisioning, might be a network issue, Retrying to provision..."
tools/provision
else
echo "\`provision\`: Something REALLY BAD went wrong with the provisioning, not retrying."
exit "$ret"
fi
}