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.
Unify the actions in the Dockerfiles between the runtime environment
and the run containers.
Fixes#2345
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
* [docker] Remove versions from Docker files
There is no dependency on an actual version, it was only there to
silence the linter. Instead the linter is now set to not warn about
it.
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
* [docker] Update to Ubuntu 20.04
Update to new Ubuntu release:
- Only GCC 9.3 available. Also add clang (10.0) now.
- SystemC is now a package 🎉
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
This adds files to build and run two Docker images:
- run: Build a Docker container that can be used as an executable
drop-in for verilator. This can be useful to test behavior of
older versions or a development version. The functionality is
pretty simplistic at the moment for a start.
- buildenv: Everything needed to build and test Verilator. Useful to
run quick tests in the cloud or try other compilers. It can
also serve as basis for further CI integration.
