CTest can't forward command line arguments to the test runner, so add
the option to using an environment variable to enable features instead.
CMake issue tracking the feature that would have been needed:
https://gitlab.kitware.com/cmake/cmake/-/issues/20470
Tests which aren't passing yet have been disabled in CI.
The C++ compiler generates implicit branches for exception handling,
which is particularly common when calling standard library functions.
It's not generally useful to have tests for the case when
std::vector::push_back fails due to an out-of-memory condition, so in
this PR we use a feature in the latest lcov release to filter out these
compiler-generated branches.
Our code coverage numbers consequently go way up!
The "src" directory got renamed to "oi" and the previous rule stopped
matching our source code. By changing to collect coverage for everything
except for "build" and "extern", we should avoid this problem in the
future.
Don't enable for local dev builds or for GCC CI builds, as every
compiler version has a different set of warnings and trying to make them
all pass is a neverending task.
CodeCov's docs say that a token isn't required for a public repository,
but our uploads have been broken for a few weeks at this point and
passing in the token fixes them...
Add CODE_COVERAGE option to enable coverage instrumentation in builds.
Add new CI job to upload coverage reports to CodeCov.io.
Reports can be found by navigating the codecov.io UI, or by going to
the URL printed at the end of the "Code Coverage" CI job. More CodeCov
integration could be set up later once we have coverage reporting on the
main branch.
This reduces the time to run tests from 5-9 minutes down to 3-4 minutes.
`nproc` is returning `1` on the CI node which is processing our
config.yml. In the absense of a better way of getting the number of CPUs
on our executor, just hardcode it.
We actually have 16 cores on our 2xlarge executors, but higher
parallelism in tests appears to cause oid to sometimes fail with SIGILL.
I'm still investigating this problem.
This will give us more flexibility later, e.g. allowing different steps
for GCC and Clang (as needed for code coverage), or letting us
parallelise our tests across multiple machines.
