|
| 1 | +# --- What this file does --------------------------------------------------------------------------------------- |
| 2 | +# JaCoCo is the Java tool that instruments test runs and records which lines of code actually executed ("exec |
| 3 | +# data"). Maven produces jacoco XML reports per module, and this project also has an `xrpl4j-coverage` module |
| 4 | +# that merges (aggregates) exec data from unit tests AND integration tests (ITs) together into one combined |
| 5 | +# report. |
| 6 | +# |
| 7 | +# We upload TWO separate reports to Codecov instead of one: |
| 8 | +# 1. "unittests" - only the per-module unit-test reports (xrpl4j-core, xrpl4j-client). This is what actually |
| 9 | +# gates PRs. (xrpl4j-mpt-crypto ships no Java sources of its own - it only bundles downloaded native |
| 10 | +# tarballs as resources - so it has nothing for JaCoCo to instrument and is excluded here.) |
| 11 | +# 2. "aggregate" - the combined unit+IT report from xrpl4j-coverage. Informational only. Lets us see the |
| 12 | +# fuller picture without letting IT coverage (which can look high without meaningfully unit-testing |
| 13 | +# anything) count toward the merge-blocking number. |
| 14 | +# --------------------------------------------------------------------------------------------------------------- |
| 15 | + |
| 16 | +coverage: |
| 17 | + status: |
| 18 | + # "project" status = coverage of the whole codebase (as opposed to "patch" status below, which only looks |
| 19 | + # at lines changed in a PR). |
| 20 | + project: |
| 21 | + unittests-gate: |
| 22 | + # Only reads uploads tagged with the `unittests` flag (see `flags:` below) - so IT-derived hits never |
| 23 | + # factor into this number. |
| 24 | + flags: |
| 25 | + - unittests |
| 26 | + # `target: auto` = don't require a fixed percentage; just don't let coverage drop below what the base |
| 27 | + # branch already has. |
| 28 | + target: auto |
| 29 | + # Allow up to a 1% drop before failing - avoids false failures from noise/rounding on small PRs. |
| 30 | + threshold: 1% |
| 31 | + # THIS is the one that should be set as a required GitHub status check in branch protection. It's the |
| 32 | + # actual quality gate. |
| 33 | + |
| 34 | + aggregate-visibility: |
| 35 | + # Reads the combined unit+IT report instead. |
| 36 | + flags: |
| 37 | + - aggregate |
| 38 | + target: auto |
| 39 | + # `informational: true` means this check always shows as passing/visible on the PR, but can never block |
| 40 | + # a merge - it's there so reviewers can see "here's what IT coverage adds on top of unit coverage," |
| 41 | + # without that number having any teeth. |
| 42 | + informational: true |
| 43 | + |
| 44 | + # "patch" status = coverage of only the NEW/changed lines in a PR. This is what usually catches "you added |
| 45 | + # a function with no test." |
| 46 | + patch: |
| 47 | + unittests-gate: |
| 48 | + flags: |
| 49 | + - unittests |
| 50 | + target: auto |
| 51 | + # No aggregate-visibility patch check on purpose: patch coverage is exactly the "did you unit test what |
| 52 | + # you just wrote" question, which is the one place blending in IT coverage would be most likely to mask |
| 53 | + # a real gap. |
| 54 | + |
| 55 | +# Flags are labels attached to a coverage upload (set in the GitHub Actions workflow via `flags: unittests` / |
| 56 | +# `flags: aggregate` on the codecov-action step). They're what let the `status:` checks above tell the two |
| 57 | +# reports apart, even though both cover the same source files. |
| 58 | +# |
| 59 | +# NOTE: `paths:` below are identical for both flags on purpose - this is NOT a copy-paste mistake. A flag's |
| 60 | +# `paths:` is a real filter on which files get attributed to it, but here both lists cover every module either |
| 61 | +# report could ever contain, so neither one actually excludes anything. The unit-vs-aggregate split happens |
| 62 | +# entirely in workflow.yml, via which jacoco.xml file each codecov-action step's `files:` argument points at |
| 63 | +# (per-module unit reports vs. the xrpl4j-coverage aggregate report). |
| 64 | +flags: |
| 65 | + unittests: |
| 66 | + paths: |
| 67 | + - xrpl4j-core/ |
| 68 | + - xrpl4j-client/ |
| 69 | + # `carryforward: false` = don't reuse a previous commit's coverage data if this flag doesn't get a fresh |
| 70 | + # upload on some commit. We always upload fresh on every build, so there's nothing to carry forward. |
| 71 | + carryforward: false |
| 72 | + |
| 73 | + aggregate: |
| 74 | + paths: |
| 75 | + - xrpl4j-core/ |
| 76 | + - xrpl4j-client/ |
| 77 | + carryforward: false |
| 78 | + |
| 79 | +# Controls the PR comment Codecov posts: show the per-flag breakdown, the diff coverage, and a file-by-file |
| 80 | +# table. |
| 81 | +comment: |
| 82 | + layout: "flags, diff, files" |
| 83 | + require_changes: false |
| 84 | + |
| 85 | +# Rewrites absolute CI build paths (e.g. /home/runner/work/xrpl4j/xrpl4j/...) down to paths relative to the |
| 86 | +# repo root, so Codecov can match reported files to the actual repo structure. Unrelated to the unit/aggregate |
| 87 | +# split above. |
1 | 88 | fixes: |
2 | 89 | - "/home/runner/work/xrpl4j/xrpl4j/::" |
0 commit comments