Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
#!/usr/bin/env bash
|
2020-12-04 15:30:46 +00:00
|
|
|
# DESCRIPTION: Verilator: CI dependency install script
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
#
|
|
|
|
# Copyright 2020 by Geza Lore. This program is free software; you
|
|
|
|
# can redistribute it and/or modify it under the terms of either the GNU
|
|
|
|
# Lesser General Public License Version 3 or the Perl Artistic License
|
|
|
|
# Version 2.0.
|
|
|
|
#
|
|
|
|
# SPDX-License-Identifier: LGPL-3.0-only OR Artistic-2.0
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
# This script runs in the 'install' phase of all jobs, in all stages. We try to
|
|
|
|
# minimize the time spent in this by selectively installing only the components
|
|
|
|
# required by the particular build stage.
|
|
|
|
################################################################################
|
|
|
|
|
|
|
|
set -e
|
|
|
|
set -x
|
|
|
|
|
2020-12-23 17:53:05 +00:00
|
|
|
cd $(dirname "$0")/..
|
|
|
|
|
2022-09-08 02:49:09 +00:00
|
|
|
# Avoid occasional cpan failures "Issued certificate has expired."
|
|
|
|
export PERL_LWP_SSL_VERIFY_HOSTNAME=0
|
2022-09-08 15:06:44 +00:00
|
|
|
echo "check_certificate = off" >> ~/.wgetrc
|
2022-09-08 02:49:09 +00:00
|
|
|
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
fatal() {
|
|
|
|
echo "ERROR: $(basename "$0"): $1" >&2; exit 1;
|
|
|
|
}
|
|
|
|
|
2020-12-04 15:30:46 +00:00
|
|
|
if [ "$CI_OS_NAME" = "linux" ]; then
|
2020-06-04 20:08:32 +00:00
|
|
|
MAKE=make
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_OS_NAME" = "osx" ]; then
|
2020-06-04 20:08:32 +00:00
|
|
|
MAKE=make
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_OS_NAME" = "freebsd" ]; then
|
2020-06-04 20:08:32 +00:00
|
|
|
MAKE=gmake
|
|
|
|
else
|
2020-12-04 15:30:46 +00:00
|
|
|
fatal "Unknown os: '$CI_OS_NAME'"
|
2020-06-04 20:08:32 +00:00
|
|
|
fi
|
|
|
|
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
install-vcddiff() {
|
|
|
|
TMP_DIR="$(mktemp -d)"
|
|
|
|
git clone https://github.com/veripool/vcddiff "$TMP_DIR"
|
2021-07-01 20:35:19 +00:00
|
|
|
git -C "${TMP_DIR}" checkout e5664be5fe39d353bf3fcb50aa05214ab7ed4ac4
|
2020-06-04 20:08:32 +00:00
|
|
|
"$MAKE" -C "${TMP_DIR}"
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
sudo cp "${TMP_DIR}/vcddiff" /usr/local/bin
|
|
|
|
}
|
|
|
|
|
2020-12-04 15:30:46 +00:00
|
|
|
if [ "$CI_BUILD_STAGE_NAME" = "build" ]; then
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
##############################################################################
|
|
|
|
# Dependencies of jobs in the 'build' stage, i.e.: packages required to
|
|
|
|
# build Verilator
|
|
|
|
|
2020-12-04 15:30:46 +00:00
|
|
|
if [ "$CI_OS_NAME" = "linux" ]; then
|
2023-01-08 01:27:00 +00:00
|
|
|
sudo apt-get update ||
|
2020-06-22 09:13:54 +00:00
|
|
|
sudo apt-get update
|
2023-01-18 00:15:54 +00:00
|
|
|
sudo apt-get install ccache help2man libfl-dev ||
|
|
|
|
sudo apt-get install ccache help2man libfl-dev
|
2023-05-24 02:25:03 +00:00
|
|
|
if [ "$CI_RUNS_ON" = "ubuntu-20.04" ]; then
|
2022-05-30 15:51:40 +00:00
|
|
|
# Some conflict of libunwind verison on 22.04, can live without it for now
|
2023-05-24 01:30:39 +00:00
|
|
|
sudo apt-get install libgoogle-perftools-dev ||
|
|
|
|
sudo apt-get install libgoogle-perftools-dev
|
2022-05-30 15:51:40 +00:00
|
|
|
fi
|
2024-09-07 14:12:35 +00:00
|
|
|
if [ "$CI_RUNS_ON" = "ubuntu-20.04" ] || [ "$CI_RUNS_ON" = "ubuntu-22.04" ] || [ "$CI_RUNS_ON" = "ubuntu-24.04" ]; then
|
2023-01-08 01:27:00 +00:00
|
|
|
sudo apt-get install libsystemc libsystemc-dev ||
|
2020-12-11 01:22:00 +00:00
|
|
|
sudo apt-get install libsystemc libsystemc-dev
|
|
|
|
fi
|
2024-09-07 14:12:35 +00:00
|
|
|
if [ "$CI_RUNS_ON" = "ubuntu-22.04" ] || [ "$CI_RUNS_ON" = "ubuntu-24.04" ]; then
|
2023-09-08 21:26:11 +00:00
|
|
|
sudo apt-get install bear mold ||
|
|
|
|
sudo apt-get install bear mold
|
2023-05-24 01:30:39 +00:00
|
|
|
fi
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_OS_NAME" = "osx" ]; then
|
2020-06-22 09:13:54 +00:00
|
|
|
brew update
|
|
|
|
brew install ccache perl gperftools
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_OS_NAME" = "freebsd" ]; then
|
2020-06-04 20:08:32 +00:00
|
|
|
sudo pkg install -y autoconf bison ccache gmake perl5
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
else
|
2020-12-04 15:30:46 +00:00
|
|
|
fatal "Unknown os: '$CI_OS_NAME'"
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
fi
|
2020-12-23 17:53:05 +00:00
|
|
|
|
2020-12-23 18:52:37 +00:00
|
|
|
if [ -n "$CCACHE_DIR" ]; then
|
|
|
|
mkdir -p "$CCACHE_DIR" && ./ci/ci-ccache-maint.bash
|
|
|
|
fi
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_BUILD_STAGE_NAME" = "test" ]; then
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
##############################################################################
|
|
|
|
# Dependencies of jobs in the 'test' stage, i.e.: packages required to
|
|
|
|
# run the tests
|
|
|
|
|
2020-12-04 15:30:46 +00:00
|
|
|
if [ "$CI_OS_NAME" = "linux" ]; then
|
2023-01-08 01:27:00 +00:00
|
|
|
sudo apt-get update ||
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
sudo apt-get update
|
2021-01-03 02:42:41 +00:00
|
|
|
# libfl-dev needed for internal coverage's test runs
|
2024-05-17 14:38:34 +00:00
|
|
|
sudo apt-get install gdb gtkwave lcov libfl-dev ccache jq z3 ||
|
|
|
|
sudo apt-get install gdb gtkwave lcov libfl-dev ccache jq z3
|
2024-09-08 17:00:03 +00:00
|
|
|
# Required for test_regress/t/t_dist_attributes.py
|
2024-09-07 14:12:35 +00:00
|
|
|
if [ "$CI_RUNS_ON" = "ubuntu-22.04" ] || [ "$CI_RUNS_ON" = "ubuntu-24.04" ]; then
|
2024-03-17 12:10:13 +00:00
|
|
|
sudo apt-get install python3-clang mold ||
|
|
|
|
sudo apt-get install python3-clang mold
|
2022-12-16 16:19:27 +00:00
|
|
|
fi
|
2024-09-07 14:12:35 +00:00
|
|
|
if [ "$CI_RUNS_ON" = "ubuntu-20.04" ] || [ "$CI_RUNS_ON" = "ubuntu-22.04" ] || [ "$CI_RUNS_ON" = "ubuntu-24.04" ]; then
|
2023-01-08 01:27:00 +00:00
|
|
|
sudo apt-get install libsystemc-dev ||
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
sudo apt-get install libsystemc-dev
|
|
|
|
fi
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_OS_NAME" = "osx" ]; then
|
2020-06-22 09:13:54 +00:00
|
|
|
brew update
|
|
|
|
# brew cask install gtkwave # fst2vcd hangs at launch, so don't bother
|
2024-05-17 14:38:34 +00:00
|
|
|
brew install ccache perl jq z3
|
2020-12-04 15:30:46 +00:00
|
|
|
elif [ "$CI_OS_NAME" = "freebsd" ]; then
|
2020-06-04 20:08:32 +00:00
|
|
|
# fst2vcd fails with "Could not open '<input file>', exiting."
|
2024-05-17 14:38:34 +00:00
|
|
|
sudo pkg install -y ccache gmake perl5 python3 jq z3
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
else
|
2020-12-04 15:30:46 +00:00
|
|
|
fatal "Unknown os: '$CI_OS_NAME'"
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
fi
|
2020-08-02 12:47:09 +00:00
|
|
|
# Common installs
|
|
|
|
install-vcddiff
|
2024-03-16 01:06:21 +00:00
|
|
|
# Workaround -fsanitize=address crash
|
|
|
|
sudo sysctl -w vm.mmap_rnd_bits=28
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
else
|
|
|
|
##############################################################################
|
|
|
|
# Unknown build stage
|
2020-12-04 15:30:46 +00:00
|
|
|
fatal "Unknown build stage: '$CI_BUILD_STAGE_NAME'"
|
Travis: Use workspaces and per job persistent ccache (#2399)
Change the Travis builds to use workspaces and persistent ccache
We proceed in 2 stages (as before, but using workspaces for
persistence):
1. In the 'build' stage, we clone the repo, build it and
save the whole checkout ($TRAVIS_BUILD_DIR) as a workspace
2. In the 'test' stage, rather than cloning the repo, multiple jobs
pull down the same workspace we built to run the tests from
This enables:
- Reuse of the build in multiple test jobs (this is what we used the Travis
cache for before)
- Each job having a separate persistent Travis cache, which now only
contains the ccache. This means all jobs, including 'build' and 'test'
jobs can make maximum use of ccache across runs. This drastically cuts
down build times when the ccache hits, which is very often the case for
'test' jobs. Also, the separate caches only store the objects build by
the particular job that owns the cache, so we can keep the per job
ccache small.
If the commit message contains '[travis ccache clear]', the ccache will
be cleared at the beginning of the build. This can be used to test build
complete within the 50 minute timeout imposed by Travis, even without a
persistent ccache.
2020-06-03 20:10:13 +00:00
|
|
|
fi
|