The emoji cache files are not available on production jobs. Also,
copying the files, creating and restoring caches doesn't add
much optimization over just rebuilding the caches here.
This allows to run scripts between extraction and install
process.
It will be used to restore npm caches for production install jobs.
We extract the tarball in the working directory so that yarn.lock and
package.json are available to restore cache.
(And also so the path is deterministic).
The tarball will be persistent across jobs in /tmp directory.
We will use this tarball to install production server in a separate
job. This makes sure we are running the production installation
as a normal user would run it and stop any package leaks between
provision and production installation scripts.
While saving cache we used thumbor.txt in as key but while
restoring cache we used thumbor-dev.txt as the key so we could
never restore zulip-venv-cache in ci builds.
Comment out any Focal jobs in circleci config file.
This is due to a recent bug that is causing some trouble
while installing python-pip in Focal.
So we are pausing Focal tests until we get stability.
The coverage data for the platform where we run the backend+frontend
tests should be complete, so there's no reason to upload coverage data
for the other platforms.
Hopefully this change will decrease the likelihood of codecov
producing flaky results.
Fixes#11079.
Because of "service redis-server start" not working properly, in "do
Bionic hack" another instance of the server was being started. However,
once in a while this would fail for unknown reasons causing flakes in
tests involving redis. The cause of the service not starting was the
error:
::1:6379: bind: Cannot assign requested address
(see https://github.com/antirez/redis/issues/3241)
This is fixed by editing /etc/redis/redis.conf to not attempt binding
on IPv6. We change "do Bionic hack" to a simple sed command,
changing the appropriate line in the file.
By default, the line is "bind 127.0.0.1 ::1".
We change it to "bind 0.0.0.0".
We initially upgraded to 2.1 under the assumption that 2.1 was necessary
to enable pipelines. This turns out to be not true. Pipelines can be enabled
from 2.0 as well. On the other hand upgrading to 2.1 requires enabling
pipelines. This resulted in broken builds across many forks that has enabled
CircleCI and not pipelines. We are also not making use of any 2.1 features
like reusable orbs, commands, and executors currently. Downgrading to 2.0 will
also allow us to use "." in the job names which makes them more readable.
This contains the minimum changes required to move to the CircleCI 2.1
configuration file format. In 2.1 job names should not contain "." in
them.
Moving to 2.1 will allow us to enable enable pipelines from CircleCI
project settings UI. Once pipeline is enabled auto-cancellation of
redundant workflows can be also enabled from the CircleCI UI.
See https://circleci.com/docs/2.0/build-processing/
Aman Agrawal
Anders Kaseorg
arpit551
Vishnu Ks
Wyatt Hoodes
Tim Abbott
Mateusz Mandera
rht