| commit | 8ba48ad869006d87abc84e2f699fbc59eb8470f8 | [log] [tgz] |
|---|---|---|
| author | Ulf Adams <ulf@engflow.com> | Wed Apr 21 10:44:09 2021 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Apr 21 10:45:15 2021 -0700 |
| tree | a01f7eacd389ef0f8299707cf69db0b11a9c7e11 | |
| parent | 2f5c575596a05d15e1669b661ce457798760cc1a [diff] |
Java coverage: fix handling of external files
When java_test rules are run with coverage, then Bazel writes a file
containing the runtime classpath using root-relative paths.
The collect_coverage.sh script then processes that file to generate
another file containing absolute paths by prefixing each of the paths
with the runfiles directory and the workspace name. It then runs the
singlejar tool on this list of jar files to merge them into a single
file.
This happens to work for all jar files in the main repository because
the runfiles path is the runfiles directory plus the workspace name
plus the root-relative path.
However, it is broken if some of the jar files come from an external
repository. It appears that singlejar errors out on the first such jar
file, generating a partial output jar file without a central directory.
The error is swallowed by the `collect_coverage.sh` script. Presence of
coverage results may thus depend on the order of classpath entries.
In order to fix this, we change the runtime classpath file to contain
runfiles-relative paths, and the coverage script to prefix them with
the runfiles directory.
Note that we reuse SourceManifestAction here, i.e., the identical code
that is also responsible for generating the runfiles directory in the
first place. This is the only reliable way to get the correct paths
into the test action.
There are more places that use `LazyWritePathsFileAction` and I suspect
that all of them are broken:
- persistent test runner support in BazelJavaSemantics (AFAIK, this
doesn't work in Bazel anyway)
- coverage w/ metadata jars in BazelJavaSemantics (not used by
JavaBinary)
- coverage source list file ('-paths-for-coverage.txt'); this probably
results in non-functioning coverage for *source files* in external
repositories
Fixes #13376.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
Closes #13377.
Change-Id: Ie9bcc92344f06e190efcb192a3b6ef9905aea352
PiperOrigin-RevId: 369687409
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
