uber/NullAway

Switch code coverage aggregation to use built-in plugin

Open

#871 opened on Nov 29, 2023

View on GitHub
 (1 comment) (0 reactions) (1 assignee)Java (3,462 stars) (288 forks)batch import
good first issuehelp wanted

Description

Sample: https://docs.gradle.org/current/samples/sample_jvm_multi_project_with_code_coverage_distribution.html we can get rid of a bunch of custom Gradle code by changing the code-coverage-report module to use this built-in aggregating technique.

Contributor guide

Tech stack
java
Domain
build systemtesting
Issue type
refactor
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
blocked
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
GradleJavacode coverage
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
The issue suggests switching the code coverage report module to use Gradle's built in code coverage aggregation plugin, as shown in the linked Gradle sample. Investigate the current module setup in the repository and compare it with the sample. Look for files like build.gradle or settings.gradle in the code coverage report directory. Consider the impact on existing custom code and ensure compatibility with the project's multi module structure.