Conversation
📝 WalkthroughWalkthroughThe PR expands the code-coverage GitHub Actions workflow from a single Linux job into three platform-specific coverage jobs (Linux, macOS, Windows), uploads per-platform coverage artifacts, and reworks deployment to assemble per-OS gcovr pages and branch/root indexes for GitHub Pages. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant GHA as "GitHub Actions"
participant RunnerLinux as "Linux Runner"
participant RunnerMac as "macOS Runner"
participant RunnerWin as "Windows Runner"
participant Artifacts as "Artifact Storage"
participant Deploy as "Deploy Job"
participant GHPages as "GitHub Pages"
GHA->>RunnerLinux: start build-linux
GHA->>RunnerMac: start build-macos
GHA->>RunnerWin: start build-windows
RunnerLinux->>RunnerLinux: setup, build, run coverage\ngenerate gcovr
RunnerLinux->>Artifacts: upload `coverage-linux`
RunnerMac->>RunnerMac: setup, patch deps, build\ngenerate gcovr
RunnerMac->>Artifacts: upload `coverage-macos`
RunnerWin->>RunnerWin: setup toolchain, build\ngenerate gcovr
RunnerWin->>Artifacts: upload `coverage-windows`
Artifacts-->>Deploy: artifacts available
Deploy->>Artifacts: download all coverage-* artifacts
Deploy->>Deploy: extract into\ngcovr-linux / gcovr-macos / gcovr-windows
Deploy->>Deploy: generate branch and root index pages
Deploy->>GHPages: push consolidated coverage site
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
An automated preview of the documentation is available at https://165.corosio.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-02-23 22:25:38 UTC |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/code-coverage.yml (1)
74-85: Confirm Linux report still builds sidebar navigation.macOS/Windows run
gcovr_build_tree.py, but Linux does not after switching tolcov-jenkins-gcc-13.sh --only-gcovr. If that script does not generate the sidebar, the Linux report will lose navigation. If missing, add a step like this:Suggested update
- name: Build and run tests & collect coverage data run: | set -xe ls -al export ORGANIZATION=${GITHUB_REPOSITORY_OWNER} export REPONAME=$(basename ${GITHUB_REPOSITORY}) export B2_CXXSTD=20 ./ci-automation/scripts/lcov-jenkins-gcc-13.sh --only-gcovr + + - name: Generate sidebar navigation + run: python3 ci-automation/scripts/gcovr_build_tree.py gcovr - name: Generate badges run: python3 ci-automation/scripts/generate_badges.py gcovr🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 74 - 85, The Linux coverage step "Build and run tests & collect coverage data" currently calls ./ci-automation/scripts/lcov-jenkins-gcc-13.sh --only-gcovr which may not produce the HTML sidebar navigation; verify whether that script (with --only-gcovr) creates the sidebar and if it does not, add an extra step after that invocation to run the tree-generator script (gcovr_build_tree.py) to construct the sidebar before the "Generate badges" step; specifically ensure you invoke python3 ci-automation/scripts/gcovr_build_tree.py (or call the equivalent function in lcov-jenkins-gcc-13.sh) so the generated gcovr output has the sidebar navigation for Linux runs.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/code-coverage.yml:
- Around line 74-85: The Linux coverage step "Build and run tests & collect
coverage data" currently calls ./ci-automation/scripts/lcov-jenkins-gcc-13.sh
--only-gcovr which may not produce the HTML sidebar navigation; verify whether
that script (with --only-gcovr) creates the sidebar and if it does not, add an
extra step after that invocation to run the tree-generator script
(gcovr_build_tree.py) to construct the sidebar before the "Generate badges"
step; specifically ensure you invoke python3
ci-automation/scripts/gcovr_build_tree.py (or call the equivalent function in
lcov-jenkins-gcc-13.sh) so the generated gcovr output has the sidebar navigation
for Linux runs.
| - name: Clone Capy | ||
| uses: actions/checkout@v6 | ||
| with: | ||
| repository: cppalliance/capy | ||
| ref: ${{ (github.ref_name == 'master' && github.ref_name) || 'develop' }} | ||
| path: capy-root | ||
|
|
||
| - name: Clone Boost | ||
| uses: alandefreitas/cpp-actions/boost-clone@v1.9.0 | ||
| id: boost-clone | ||
| with: | ||
| branch: ${{ (github.ref_name == 'master' && github.ref_name) || 'develop' }} | ||
| boost-dir: boost-source | ||
| modules-exclude-paths: '' | ||
| scan-modules-dir: corosio-root | ||
| scan-modules-ignore: corosio,capy |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the workflow file and check the specified line ranges
cat -n .github/workflows/code-coverage.yml | sed -n '110,135p'Repository: cppalliance/corosio
Length of output: 1036
🏁 Script executed:
# Also check the second location mentioned (lines 256-272)
cat -n .github/workflows/code-coverage.yml | sed -n '252,276p'Repository: cppalliance/corosio
Length of output: 982
🌐 Web query:
GitHub Actions github.ref_name pull_request event behavior documentation
💡 Result:
For workflows triggered by the pull_request event, github.ref_name is not the source branch name. GitHub sets it based on github.ref (the ref that “triggered” the run):
-
Open / unmerged PR:
github.ref=refs/pull/<pr_number>/mergegithub.ref_name=<pr_number>/merge(e.g.,123/merge) [1]GITHUB_SHApoints to the PR merge commit (the synthetic merge of head into base) [2]
-
PR closed:
GITHUB_REF(and thusgithub.ref/github.ref_name) differs depending on whether it was merged or just closed without merging [2]. (GitHub also fixed edge cases to ensureGITHUB_REF/github.refare fully-formed refs when a PR is merged.) [3]
If you want actual branch names in a PR workflow:
- Source branch (the contributor branch):
github.head_ref[1] - Target branch (the base branch):
github.base_ref[1]
Sources: GitHub Actions contexts (github.ref_name, head_ref, base_ref) [1], events trigger docs (pull_request ref/SHA behavior) [2], GitHub changelog on GITHUB_REF/github.ref merged-PR behavior [3].
Use PR base branch for Capy/Boost checkouts.
On pull_request events, github.ref_name is set to <pr_number>/merge rather than the actual branch names. This means non-master PRs (including PRs targeting master) will fail the github.ref_name == 'master' check and always resolve to develop, causing coverage builds to diverge from the target branch. Use github.base_ref for PRs to check out the target branch instead.
Suggested update
- ref: ${{ (github.ref_name == 'master' && github.ref_name) || 'develop' }}
+ ref: ${{ github.event_name == 'pull_request' && github.base_ref || github.ref_name }}Apply to both Capy (line 118) and Boost (line 125) checkouts in the macOS job, and to both in the Windows job (lines 260 and 267).
|
GCOVR code coverage report https://165.corosio.prtest3.cppalliance.org/gcovr/index.html Build time: 2026-02-23 22:29:43 UTC |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
.github/workflows/code-coverage.yml (2)
114-129: Usegithub.base_reffor PR events when selecting the Capy/Boost branch.The
github.ref_name == 'master'condition on lines 118 and 125 evaluates tofalsefor allpull_requestruns becausegithub.ref_nameresolves to<pr_number>/mergeon that event, not the target branch name. Both checkouts will silently fall back todevelop.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 114 - 129, The branch selection logic in the "Clone Capy" and "Clone Boost" steps uses github.ref_name which is incorrect for pull_request events; update the ref expressions for both steps (the Capy `ref:` and the Boost `branch:` fields) to prefer github.ref_name but fall back to github.base_ref when present (i.e., use github.base_ref for PR events) so the checkouts target the PR base branch instead of always falling back to develop.
267-282: Samegithub.ref_namePR-event issue as the macOS job — lines 271 and 278 will always resolve todevelopfor PRs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 267 - 282, The checkout/clone steps "Clone Capy" and "Clone Boost" use the expression that always yields 'develop' during PR events because github.ref_name is not set for PRs; update the ref/branch expressions to use the PR head branch when the event is a pull_request (e.g., use github.event_name == 'pull_request' ? github.head_ref : github.ref_name or similar) so the steps in the jobs (the actions/checkout@v6 and alandefreitas/cpp-actions/boost-clone@v1.9.0 steps) correctly check out the PR branch instead of defaulting to develop.
🧹 Nitpick comments (2)
.github/workflows/code-coverage.yml (2)
30-33:pull_requesttrigger is missing apathsfilter.The
pushtrigger narrows tosrc/**,include/**, and the workflow file, but thepull_requesttrigger has no such restriction. Any PR that touches docs, configs, or any other file will spin up all three 120-minute coverage builds without producing a deployment.🔧 Suggested fix
pull_request: branches: - master - develop + paths: + - 'src/**' + - 'include/**' + - '.github/workflows/code-coverage.yml'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 30 - 33, Add the same paths filter used in the push trigger to the pull_request trigger so PRs only run coverage for relevant code changes: update the pull_request block (which currently lists branches master and develop) to include a paths array that mirrors the push trigger (e.g. src/**, include/**, and the workflow file .github/workflows/code-coverage.yml) so unrelated PRs won’t kick off the long coverage builds.
183-186:ref-source-dirhardcodes the repo name; use thepatchstep'smoduleoutput instead.
BOOST_INCLUDE_LIBRARIESalready references${{ steps.patch.outputs.module }}, butref-source-diris hardcoded tocorosio. The same fix applies to line 341 inbuild-windows.🔧 Suggested fix (apply at lines 186 and 341)
- ref-source-dir: boost-root/libs/corosio + ref-source-dir: boost-root/libs/${{ steps.patch.outputs.module }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 183 - 186, The workflow hardcodes ref-source-dir to boost-root/libs/corosio; update both occurrences (the ref-source-dir keys in the build steps and the analogous entry in build-windows) to use the patch step's module output instead by replacing the literal "boost-root/libs/corosio" with a dynamic reference to ${{ steps.patch.outputs.module }} (same value used by BOOST_INCLUDE_LIBRARIES) so the ref-source-dir follows the patched module name.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/code-coverage.yml:
- Around line 83-90: The Linux coverage upload step omits running the sidebar
generation script, so add a step to the build-linux job to run "python3
ci-automation/scripts/gcovr_build_tree.py gcovr" (same as
build-macos/build-windows) before the "Generate badges" and "Upload coverage
artifact" steps; update the build-linux job to call the gcovr_build_tree.py
script (referencing gcovr_build_tree.py and the build-linux job) so the uploaded
gcovr/ HTML includes the sidebar navigation.
- Around line 367-385: The gcovr invocation can silently produce 0% on Windows
because it doesn't set --gcov-executable; update the gcovr step to pass an
explicit --gcov-executable matching the installed gcov binary (use the same
detection logic/pattern used in ci.yml that picks versioned binaries like
gcov-14), e.g., determine the correct gcov binary name before the gcovr call and
add --gcov-executable "<detected-binary>" to the gcovr command so the gcovr
invocation (the block with gcovr and flags including --root, --filter and
--html) uses the correct gcov on Windows.
---
Duplicate comments:
In @.github/workflows/code-coverage.yml:
- Around line 114-129: The branch selection logic in the "Clone Capy" and "Clone
Boost" steps uses github.ref_name which is incorrect for pull_request events;
update the ref expressions for both steps (the Capy `ref:` and the Boost
`branch:` fields) to prefer github.ref_name but fall back to github.base_ref
when present (i.e., use github.base_ref for PR events) so the checkouts target
the PR base branch instead of always falling back to develop.
- Around line 267-282: The checkout/clone steps "Clone Capy" and "Clone Boost"
use the expression that always yields 'develop' during PR events because
github.ref_name is not set for PRs; update the ref/branch expressions to use the
PR head branch when the event is a pull_request (e.g., use github.event_name ==
'pull_request' ? github.head_ref : github.ref_name or similar) so the steps in
the jobs (the actions/checkout@v6 and
alandefreitas/cpp-actions/boost-clone@v1.9.0 steps) correctly check out the PR
branch instead of defaulting to develop.
---
Nitpick comments:
In @.github/workflows/code-coverage.yml:
- Around line 30-33: Add the same paths filter used in the push trigger to the
pull_request trigger so PRs only run coverage for relevant code changes: update
the pull_request block (which currently lists branches master and develop) to
include a paths array that mirrors the push trigger (e.g. src/**, include/**,
and the workflow file .github/workflows/code-coverage.yml) so unrelated PRs
won’t kick off the long coverage builds.
- Around line 183-186: The workflow hardcodes ref-source-dir to
boost-root/libs/corosio; update both occurrences (the ref-source-dir keys in the
build steps and the analogous entry in build-windows) to use the patch step's
module output instead by replacing the literal "boost-root/libs/corosio" with a
dynamic reference to ${{ steps.patch.outputs.module }} (same value used by
BOOST_INCLUDE_LIBRARIES) so the ref-source-dir follows the patched module name.
| - name: Generate gcovr report | ||
| run: | | ||
| set -xe | ||
| module=$(basename ${GITHUB_REPOSITORY}) | ||
| mkdir -p gcovr | ||
|
|
||
| gcovr \ | ||
| --root boost-root \ | ||
| --merge-mode-functions separate -p \ | ||
| --html-nested \ | ||
| --exclude-unreachable-branches \ | ||
| --exclude-throw-branches \ | ||
| --exclude '.*/test/.*' \ | ||
| --exclude '.*/extra/.*' \ | ||
| --exclude '.*/example/.*' \ | ||
| --exclude '.*/examples/.*' \ | ||
| --filter ".*/${module}/.*" \ | ||
| --html --output gcovr/index.html \ | ||
| boost-root/__build_cmake_test__ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd /tmp && find . -name "code-coverage.yml" -type f 2>/dev/null | head -5Repository: cppalliance/corosio
Length of output: 45
🏁 Script executed:
git ls-files '.github/workflows/*.yml'Repository: cppalliance/corosio
Length of output: 150
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | sed -n '320,390p'Repository: cppalliance/corosio
Length of output: 2962
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | sed -n '1,366p' | tail -100Repository: cppalliance/corosio
Length of output: 4147
🏁 Script executed:
rg "macos|darwin|gcov-executable" -i -B 2 -A 2 .github/workflows/code-coverage.ymlRepository: cppalliance/corosio
Length of output: 1315
🏁 Script executed:
grep -n "jobs:" .github/workflows/code-coverage.ymlRepository: cppalliance/corosio
Length of output: 71
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | sed -n '240,290p'Repository: cppalliance/corosio
Length of output: 1749
🏁 Script executed:
rg "build-windows|setup-cpp" -B 5 -A 15 .github/workflows/code-coverage.yml | head -80Repository: cppalliance/corosio
Length of output: 2253
🏁 Script executed:
web_search
setup-cpp alandefreitas mingw gcov executable PATHRepository: cppalliance/corosio
Length of output: 161
🏁 Script executed:
rg "mingw.*gcov|gcov.*mingw" -i .Repository: cppalliance/corosio
Length of output: 45
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | grep -A 5 "setup-cpp.outputs"Repository: cppalliance/corosio
Length of output: 828
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | sed -n '1,70p'Repository: cppalliance/corosio
Length of output: 2141
🌐 Web query:
alandefreitas cpp-actions setup-cpp mingw gcov
💡 Result:
In alandefreitas/cpp-actions, the Setup C++ action does not install MinGW. If you set compiler: mingw, it will only look for gcc/g++ already on PATH (so you must install MinGW yourself, e.g., via MSYS2/WinLibs, and ensure bin/ is on PATH). [1]
For gcov-based coverage with MinGW/GCC:
- Ensure the toolchain provides
gcov(it normally ships with GCC/MinGW and must be onPATH). - Build with coverage instrumentation flags, run tests to generate coverage data, then run
gcovrto produce reports. [2]
If you want an action that can install MinGW + gcovr as part of setup, aminya/setup-cpp explicitly supports mingw and includes coverage tooling like gcovr. [3]
Sources: Setup C++ (cpp-actions) MinGW behavior [1], gcovr “Compiling for Coverage” workflow/requirements [2], aminya/setup-cpp supported tools (mingw, gcovr) [3].
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | grep -i "mingw\|msys\|install"Repository: cppalliance/corosio
Length of output: 578
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | sed -n '245,350p'Repository: cppalliance/corosio
Length of output: 4153
🌐 Web query:
windows-2022 github actions runner mingw gcc gcov pre-installed
💡 Result:
Yes—on the GitHub-hosted windows-2022 runner, MSYS2 is pre-installed (at C:\msys64, not added to PATH by default) and the image also includes GCC (currently listed as gcc 14.2.0 in the Windows 2022 image readme). [1]
gcov is part of the GCC suite (the MSYS2 GCC package installs gcov.exe, gcov-tool.exe, etc.), so if you’re using the preinstalled GCC toolchain on the runner, gcov is available as well. [2]
Sources: [1] [2]
🏁 Script executed:
git log --oneline --all -20 | head -20Repository: cppalliance/corosio
Length of output: 1181
🏁 Script executed:
cat -n .github/workflows/code-coverage.yml | sed -n '357,390p'Repository: cppalliance/corosio
Length of output: 1421
🏁 Script executed:
rg "GCOV|gcov|coverage.*windows|windows.*coverage" -i --type yaml .github/Repository: cppalliance/corosio
Length of output: 3528
Windows gcovr call is missing --gcov-executable and may silently produce 0% coverage.
The macOS job explicitly specifies --gcov-executable "xcrun llvm-cov gcov". On Windows with GCC, the coverage binary is often version-suffixed (e.g., gcov-14), not available as the bare gcov name. The ci.yml workflow already demonstrates awareness of this by checking for version-suffixed gcov binaries. Without the explicit flag, gcovr silently finds no .gcda files and emits an empty report with 0% coverage.
Specify the exact binary name, matching the pattern used in ci.yml:
gcovr \
--root boost-root \
+ --gcov-executable gcov \
--merge-mode-functions separate -p \(Check recent Windows workflow runs or the setup-cpp outputs to confirm the actual binary name, e.g., gcov-14.)
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Generate gcovr report | |
| run: | | |
| set -xe | |
| module=$(basename ${GITHUB_REPOSITORY}) | |
| mkdir -p gcovr | |
| gcovr \ | |
| --root boost-root \ | |
| --merge-mode-functions separate -p \ | |
| --html-nested \ | |
| --exclude-unreachable-branches \ | |
| --exclude-throw-branches \ | |
| --exclude '.*/test/.*' \ | |
| --exclude '.*/extra/.*' \ | |
| --exclude '.*/example/.*' \ | |
| --exclude '.*/examples/.*' \ | |
| --filter ".*/${module}/.*" \ | |
| --html --output gcovr/index.html \ | |
| boost-root/__build_cmake_test__ | |
| - name: Generate gcovr report | |
| run: | | |
| set -xe | |
| module=$(basename ${GITHUB_REPOSITORY}) | |
| mkdir -p gcovr | |
| gcovr \ | |
| --root boost-root \ | |
| --gcov-executable gcov \ | |
| --merge-mode-functions separate -p \ | |
| --html-nested \ | |
| --exclude-unreachable-branches \ | |
| --exclude-throw-branches \ | |
| --exclude '.*/test/.*' \ | |
| --exclude '.*/extra/.*' \ | |
| --exclude '.*/example/.*' \ | |
| --exclude '.*/examples/.*' \ | |
| --filter ".*/${module}/.*" \ | |
| --html --output gcovr/index.html \ | |
| boost-root/__build_cmake_test__ |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/code-coverage.yml around lines 367 - 385, The gcovr
invocation can silently produce 0% on Windows because it doesn't set
--gcov-executable; update the gcovr step to pass an explicit --gcov-executable
matching the installed gcov binary (use the same detection logic/pattern used in
ci.yml that picks versioned binaries like gcov-14), e.g., determine the correct
gcov binary name before the gcovr call and add --gcov-executable
"<detected-binary>" to the gcovr command so the gcovr invocation (the block with
gcovr and flags including --root, --filter and --html) uses the correct gcov on
Windows.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/code-coverage.yml (1)
36-38:⚠️ Potential issue | 🟠 MajorFixed concurrency group serializes all coverage runs across all branches and PRs.
code-coverage-pagesis a single global queue withcancel-in-progress: false. Adeveloppush must wait for an in-progressmasterpush to fully complete (up to 120 min), and all PR runs also queue behind pushes — even though PR runs never deploy. This creates unnecessary delays.Consider scoping the concurrency group per ref, or at least separating PR runs from push/deploy runs:
Suggested fix
concurrency: - group: code-coverage-pages + group: code-coverage-${{ github.event_name == 'pull_request' && github.event.pull_request.number || github.ref_name }} cancel-in-progress: falseIf the intent is to serialize only deployments to the
code-coveragebranch, the concurrency group should be on thedeployjob alone rather than the entire workflow.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 36 - 38, The workflow's global concurrency group "code-coverage-pages" with cancel-in-progress: false serializes all branches and PRs; change the concurrency to be per-ref or restrict it to the deploy job only. Update the concurrency group string (currently "group: code-coverage-pages") to include the ref (e.g., append a ref token like github.ref or github.ref_name) so runs for different branches don't queue each other, and/or move the concurrency block out of the top-level workflow and into the "deploy" job so only deploys to the coverage branch are serialized and PR runs are not affected.
♻️ Duplicate comments (3)
.github/workflows/code-coverage.yml (3)
114-129:⚠️ Potential issue | 🟠 Major
github.ref_nameresolves to<pr_number>/mergeonpull_requestevents — Capy and Boost will always check outdevelop.On
pull_requestevents,github.ref_nameis<pr_number>/merge, not the target branch. The== 'master'check always fails, so PRs targetingmasterwill incorrectly usedevelopfor Capy and Boost. The same issue exists in the Windows job (lines 280, 287).Use
github.base_reffor PR events:Suggested fix (apply to both macOS and Windows jobs)
- ref: ${{ (github.ref_name == 'master' && github.ref_name) || 'develop' }} + ref: ${{ github.event_name == 'pull_request' && github.base_ref || (github.ref_name == 'master' && 'master') || 'develop' }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 114 - 129, The workflow uses github.ref_name in the "Clone Capy" and "Clone Boost" steps which resolves to "<pr_number>/merge" for pull_request events and causes the branch check to always fall back to 'develop'; update the conditional expressions for the Capy step's ref and the Boost step's branch to use github.base_ref when github.event_name == 'pull_request' (i.e., prefer github.base_ref for PRs, otherwise use github.ref_name) so PRs targeting master will correctly check out the target branch; apply the same change to the equivalent Windows job clone steps.
83-90:⚠️ Potential issue | 🟡 MinorLinux job is missing the sidebar navigation step and
--jsonflag for badge generation.Both
build-macos(lines 242-246) andbuild-windows(lines 405-409) rungcovr_build_tree.py gcovrbefore uploading and pass--json gcovr/summary.jsontogenerate_badges.py. The Linux job has neither, so the Linux artifact will lack sidebar navigation and badge generation may behave differently.Suggested fix
+ - name: Generate sidebar navigation + run: python3 ci-automation/scripts/gcovr_build_tree.py gcovr + - name: Generate badges - run: python3 ci-automation/scripts/generate_badges.py gcovr + run: python3 ci-automation/scripts/generate_badges.py gcovr --json gcovr/summary.json - name: Upload coverage artifact🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 83 - 90, The Linux workflow is missing the gcovr build-tree step and the --json flag when invoking generate_badges.py, so add a step that runs gcovr_build_tree.py gcovr (same as build-macos/build-windows) before badge generation and change the generate_badges.py invocation to include --json gcovr/summary.json so badges and sidebar navigation are generated consistently; ensure the steps reference the same artifact folder name "gcovr" and the script names generate_badges.py and gcovr_build_tree.py to locate the correct places to modify.
384-403:⚠️ Potential issue | 🟠 MajorWindows
gcovrcall is missing--gcov-executable, risking 0% coverage reports.The macOS job correctly passes
--gcov-executable "xcrun llvm-cov gcov"(line 228), but the Windows job omits this flag. On thewindows-2022runner with MinGW,gcovmay not be onPATHor may be version-suffixed (e.g.,gcov-14), causinggcovrto silently produce empty reports.Suggested fix
gcovr \ --root boost-root \ + --gcov-executable gcov \ --merge-mode-functions separate -p \Verify which
gcovbinary is available on the runner (gcov,gcov-14, etc.) and use the exact name.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 384 - 403, The Windows gcovr invocation (the gcovr command block) omits the --gcov-executable flag, which can cause 0% reports on windows-2022; update that gcovr call to pass --gcov-executable with the correct gcov binary name found on the runner (e.g., "gcov-14" or "gcov")—first probe or hardcode the known MinGW/Runner binary, then add --gcov-executable "<binary>" to the gcovr arguments so gcovr uses the intended gcov executable.
🧹 Nitpick comments (4)
.github/workflows/code-coverage.yml (4)
30-33:pull_requesttrigger is missingpathsfilter, unlikepush.The
pushtrigger (lines 26-29) restricts runs to changes insrc/**,include/**, and this workflow file, butpull_requesthas no such filter. This means every PR targetingmaster/develop— even documentation-only changes — will trigger three expensive coverage builds (120-min timeout each).Suggested fix
pull_request: branches: - master - develop + paths: + - 'src/**' + - 'include/**' + - '.github/workflows/code-coverage.yml'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 30 - 33, Add the same paths filter to the pull_request trigger as used by push so PRs only run coverage when relevant files change: update the pull_request block (targeting master and develop) to include a paths: entry with the same patterns used for push (e.g. src/**, include/**, and .github/workflows/code-coverage.yml) so documentation-only or unrelated PRs do not trigger the expensive coverage jobs.
131-163: Patch Boost steps are near-identical across macOS and Windows — consider a composite action or reusable workflow.The "Patch Boost" step bodies in
build-macos(lines 131-163) andbuild-windows(lines 293-324) are character-for-character duplicates. If one is updated (e.g., to fix path handling), the other must be manually kept in sync. Extracting this into a composite action or a reusable workflow step would reduce duplication and maintenance risk.Also applies to: 293-324
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 131 - 163, The "Patch Boost" step (step id patch) in the build-macos and build-windows jobs is duplicated; extract the repeated shell block into a single reusable workflow or composite action and replace each in-line step with a single uses: reference; specifically create a composite action (or a reusable workflow file) that accepts inputs for GITHUB_REPOSITORY/GITHUB_WORKSPACE and performs the same operations (set -xe, module assignment, workspace_root normalization, sparse-checkout handling, cp -rL boost-source boost-root, boost_root normalization, and copying corosio-root/capy-root into libs/$module and libs/capy), then update the build-macos and build-windows jobs to call that action (keeping the step id patch) and pass required inputs to eliminate the character-for-character duplication.
202-218: Debug/diagnostic steps should be removed or gated before merge.The "Locate build output" steps on macOS (lines 202-218) and Windows (lines 366-382) are debug aids (
ls,find,head) that add noise to CI logs. They appear to be leftover from the iterative troubleshooting commits ("Log verbose", "More loggin"). Consider removing them or wrapping them in anif: runner.debugguard so they only run when re-run with debug logging enabled.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 202 - 218, The "Locate build output" CI step (step name: "Locate build output") contains noisy debug commands (ls, find, head, xcrun llvm-cov gcov) that should not run on every merge; either remove these diagnostic commands entirely or gate the whole step behind a conditional so it only runs when debug logging is enabled (e.g., wrap under an if: runner.debug or similar CI debug flag). Apply the same change to the duplicate Windows diagnostic block later in the file so both macOS and Windows debug sections are either removed or conditional.
339-340: Redundant coverage flags on Windows build.
--coveragealready implies-fprofile-arcs -ftest-coverage, so specifying all three is redundant. Not harmful, but noisy.-fprofile-update=atomicis the only additional flag needed.Suggested cleanup
- cxxflags: '--coverage -fprofile-arcs -ftest-coverage -fprofile-update=atomic' - ccflags: '--coverage -fprofile-arcs -ftest-coverage -fprofile-update=atomic' + cxxflags: '--coverage -fprofile-update=atomic' + ccflags: '--coverage -fprofile-update=atomic'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 339 - 340, The cxxflags and ccflags lines duplicate flags because --coverage already implies -fprofile-arcs and -ftest-coverage; update the two entries (cxxflags and ccflags) to remove the redundant flags and keep just --coverage plus the additional -fprofile-update=atomic flag (e.g., set each to '--coverage -fprofile-update=atomic') so the Windows build configuration is concise.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/code-coverage.yml:
- Around line 417-419: The deploy job currently uses if: ${{ !cancelled() &&
github.event_name != 'pull_request' }} which allows deploy even when some build
jobs failed; change the deploy job condition to require overall success (e.g.
if: ${{ success() && !cancelled() && github.event_name != 'pull_request' }}) so
deploy runs only when all platform builds pass, or alternatively implement a
dynamic branch index generation step (the branch index pages generation) that
only emits links for platforms whose artifacts were successfully downloaded, or
add placeholder index.html files per platform to indicate "build pending/failed"
— update the deploy job condition in the deploy stanza and/or adjust the branch
index generation logic that creates the platform links accordingly.
---
Outside diff comments:
In @.github/workflows/code-coverage.yml:
- Around line 36-38: The workflow's global concurrency group
"code-coverage-pages" with cancel-in-progress: false serializes all branches and
PRs; change the concurrency to be per-ref or restrict it to the deploy job only.
Update the concurrency group string (currently "group: code-coverage-pages") to
include the ref (e.g., append a ref token like github.ref or github.ref_name) so
runs for different branches don't queue each other, and/or move the concurrency
block out of the top-level workflow and into the "deploy" job so only deploys to
the coverage branch are serialized and PR runs are not affected.
---
Duplicate comments:
In @.github/workflows/code-coverage.yml:
- Around line 114-129: The workflow uses github.ref_name in the "Clone Capy" and
"Clone Boost" steps which resolves to "<pr_number>/merge" for pull_request
events and causes the branch check to always fall back to 'develop'; update the
conditional expressions for the Capy step's ref and the Boost step's branch to
use github.base_ref when github.event_name == 'pull_request' (i.e., prefer
github.base_ref for PRs, otherwise use github.ref_name) so PRs targeting master
will correctly check out the target branch; apply the same change to the
equivalent Windows job clone steps.
- Around line 83-90: The Linux workflow is missing the gcovr build-tree step and
the --json flag when invoking generate_badges.py, so add a step that runs
gcovr_build_tree.py gcovr (same as build-macos/build-windows) before badge
generation and change the generate_badges.py invocation to include --json
gcovr/summary.json so badges and sidebar navigation are generated consistently;
ensure the steps reference the same artifact folder name "gcovr" and the script
names generate_badges.py and gcovr_build_tree.py to locate the correct places to
modify.
- Around line 384-403: The Windows gcovr invocation (the gcovr command block)
omits the --gcov-executable flag, which can cause 0% reports on windows-2022;
update that gcovr call to pass --gcov-executable with the correct gcov binary
name found on the runner (e.g., "gcov-14" or "gcov")—first probe or hardcode the
known MinGW/Runner binary, then add --gcov-executable "<binary>" to the gcovr
arguments so gcovr uses the intended gcov executable.
---
Nitpick comments:
In @.github/workflows/code-coverage.yml:
- Around line 30-33: Add the same paths filter to the pull_request trigger as
used by push so PRs only run coverage when relevant files change: update the
pull_request block (targeting master and develop) to include a paths: entry with
the same patterns used for push (e.g. src/**, include/**, and
.github/workflows/code-coverage.yml) so documentation-only or unrelated PRs do
not trigger the expensive coverage jobs.
- Around line 131-163: The "Patch Boost" step (step id patch) in the build-macos
and build-windows jobs is duplicated; extract the repeated shell block into a
single reusable workflow or composite action and replace each in-line step with
a single uses: reference; specifically create a composite action (or a reusable
workflow file) that accepts inputs for GITHUB_REPOSITORY/GITHUB_WORKSPACE and
performs the same operations (set -xe, module assignment, workspace_root
normalization, sparse-checkout handling, cp -rL boost-source boost-root,
boost_root normalization, and copying corosio-root/capy-root into libs/$module
and libs/capy), then update the build-macos and build-windows jobs to call that
action (keeping the step id patch) and pass required inputs to eliminate the
character-for-character duplication.
- Around line 202-218: The "Locate build output" CI step (step name: "Locate
build output") contains noisy debug commands (ls, find, head, xcrun llvm-cov
gcov) that should not run on every merge; either remove these diagnostic
commands entirely or gate the whole step behind a conditional so it only runs
when debug logging is enabled (e.g., wrap under an if: runner.debug or similar
CI debug flag). Apply the same change to the duplicate Windows diagnostic block
later in the file so both macOS and Windows debug sections are either removed or
conditional.
- Around line 339-340: The cxxflags and ccflags lines duplicate flags because
--coverage already implies -fprofile-arcs and -ftest-coverage; update the two
entries (cxxflags and ccflags) to remove the redundant flags and keep just
--coverage plus the additional -fprofile-update=atomic flag (e.g., set each to
'--coverage -fprofile-update=atomic') so the Windows build configuration is
concise.
mvandeberg
force-pushed
the
pr/win-mac-coverage
branch
from
94fe0f3 to
d0b6bda
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (5)
.github/workflows/code-coverage.yml (5)
464-466: Deploy with!cancelled()can publish broken links — already flagged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 464 - 466, The deploy job currently uses if: ${{ !cancelled() }} which allows running even if builds failed; change the condition on the deploy job (named deploy) to require successful completion of the dependent build jobs by replacing the if with a check that each need succeeded, e.g. if: ${{ needs['build-linux'].result == 'success' && needs['build-macos'].result == 'success' && needs['build-windows'].result == 'success' }}, so deploy only runs when all three builds passed.
149-164:github.ref_nameresolves to<pr_number>/mergeonpull_requestevents — already flagged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 149 - 164, The workflow uses github.ref_name which on pull_request events resolves to "<pr_number>/merge", causing incorrect branch refs for both the actions/checkout step (name: Clone Capy) and the alandefreitas/cpp-actions/boost-clone step (id: boost-clone); update the ref/branch expressions to use github.head_ref for PRs (or fall back to github.ref_name for push) — e.g. replace occurrences of ${{ (github.ref_name == 'master' && github.ref_name) || 'develop' }} with a conditional that prefers github.head_ref when github.event_name == 'pull_request' (or uses github.head_ref || github.ref_name || 'develop'), and apply the same change for the boost-clone branch input to ensure correct branch resolution for PR workflows.
339-354:github.ref_namebranch resolution onpull_requestevents — already flagged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 339 - 354, The workflow uses github.ref_name for branch selection in the "Clone Capy" (ref:) and "Clone Boost" (branch:) steps, which fails for pull_request events; update both expressions to pick github.head_ref when github.event_name == 'pull_request', otherwise github.ref_name, and fall back to 'develop' if neither is present (e.g. use an expression like: ${{ (github.event_name == 'pull_request' && github.head_ref) || github.ref_name || 'develop' }}). Ensure you update both the ref: in the Clone Capy step and the branch: in the Clone Boost step.
79-86: Linux job is missing the sidebar navigation step — already flagged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 79 - 86, The Linux workflow is missing the sidebar navigation step that other jobs include; insert a step named like "Generate sidebar navigation" (matching the same step used in the other OS jobs) into the sequence between the "Generate badges" and "Upload coverage artifact" steps so the job runs the same sidebar/navigation generation script prior to uploading the coverage artifact; ensure the step uses the same run command or action and any inputs used by the corresponding step in the other job to keep behavior consistent.
431-450: Missing--gcov-executableon Windowsgcovrinvocation — already flagged.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 431 - 450, The gcovr invocation in the "Generate gcovr report" step must supply --gcov-executable on Windows; update the gcovr command in that step (the gcovr block) to set a gcov path based on RUNNER_OS (e.g., in the shell before calling gcovr: if [ "${RUNNER_OS}" = "Windows" ]; then gcov_exe="gcov.exe"; else gcov_exe="gcov"; fi) and pass --gcov-executable "${gcov_exe}" to the gcovr invocation so Windows runners use gcov.exe while Unix uses the default.
🧹 Nitpick comments (3)
.github/workflows/code-coverage.yml (2)
402-403: Redundant coverage instrumentation flags.
--coverageis already a GCC shorthand for both-fprofile-arcsand-ftest-coverage. Specifying all three is harmless but adds noise; the macOS job uses--coveragealone (line 211).♻️ Suggested cleanup
- cxxflags: '--coverage -fprofile-arcs -ftest-coverage -fprofile-update=atomic' - ccflags: '--coverage -fprofile-arcs -ftest-coverage -fprofile-update=atomic' + cxxflags: '--coverage -fprofile-update=atomic' + ccflags: '--coverage -fprofile-update=atomic'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 402 - 403, The cxxflags and ccflags entries add redundant coverage flags; replace the three flags with the single GCC shorthand by keeping only "--coverage" for both cxxflags and ccflags (remove "-fprofile-arcs" and "-ftest-coverage" while leaving any existing "-fprofile-update=atomic" if desired or remove it if you want exact parity with the macOS job), updating the entries named cxxflags and ccflags accordingly so the Linux job matches the macOS job’s simpler instrumentation.
544-552: Root index<head>is missing a<title>.The branch index pages (lines 530-531) include a
<title>Code Coverage</title>, but the rootindex.htmlhas an empty<head>.✏️ Suggested fix
cat > gh_pages_dir/index.html << 'HTMLEOF' <html> - <head></head> + <head><title>Code Coverage</title></head> <body>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/code-coverage.yml around lines 544 - 552, The root gh_pages_dir/index.html generated by the here-doc lacks a <title>; update the here-doc block that writes gh_pages_dir/index.html to include a <title>Code Coverage</title> inside the <head> (i.e., change the <head></head> in the here-doc to <head><title>Code Coverage</title></head>) so the root index matches the branch pages.README.md (1)
3-4: LGTM — minor: badge alt text could be platform-specific.All six new coverage badges share the generic alt text
"Lines". Differentiating them (e.g.,"Linux lines","macOS lines","Windows lines") would make them distinguishable for screen readers and in contexts where images don't render.✏️ Suggested alt text update
-[](...) | [](...) | [](...) +[](...) | [](...) | [](...)Apply the same change to the
developrow.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@README.md` around lines 3 - 4, Update the six coverage badge image alt texts that currently use the generic string "Lines" to platform-specific labels: replace alt="Lines" with alt="Linux lines", alt="macOS lines", and alt="Windows lines" for the corresponding gcovr-linux, gcovr-macos, and gcovr-windows badges in both the master and develop rows; locate the image markdown entries containing the badge URLs (gcovr-linux/badges/coverage-lines.svg, gcovr-macos/badges/coverage-lines.svg, gcovr-windows/badges/coverage-lines.svg) and change their alt attributes accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/code-coverage.yml:
- Around line 79-80: The Linux badge-generation step calling "python3
ci-automation/scripts/generate_badges.py gcovr" omits the --json
gcovr/summary.json flag, so add the missing flag to that invocation (make it
"generate_badges.py gcovr --json gcovr/summary.json") to match the macOS and
Windows steps; this ensures the generate_badges.py script receives the explicit
summary JSON path produced by lcov-jenkins-gcc-13.sh --only-gcovr and prevents
silent failures or incorrect badges.
---
Duplicate comments:
In @.github/workflows/code-coverage.yml:
- Around line 464-466: The deploy job currently uses if: ${{ !cancelled() }}
which allows running even if builds failed; change the condition on the deploy
job (named deploy) to require successful completion of the dependent build jobs
by replacing the if with a check that each need succeeded, e.g. if: ${{
needs['build-linux'].result == 'success' && needs['build-macos'].result ==
'success' && needs['build-windows'].result == 'success' }}, so deploy only runs
when all three builds passed.
- Around line 149-164: The workflow uses github.ref_name which on pull_request
events resolves to "<pr_number>/merge", causing incorrect branch refs for both
the actions/checkout step (name: Clone Capy) and the
alandefreitas/cpp-actions/boost-clone step (id: boost-clone); update the
ref/branch expressions to use github.head_ref for PRs (or fall back to
github.ref_name for push) — e.g. replace occurrences of ${{ (github.ref_name ==
'master' && github.ref_name) || 'develop' }} with a conditional that prefers
github.head_ref when github.event_name == 'pull_request' (or uses
github.head_ref || github.ref_name || 'develop'), and apply the same change for
the boost-clone branch input to ensure correct branch resolution for PR
workflows.
- Around line 339-354: The workflow uses github.ref_name for branch selection in
the "Clone Capy" (ref:) and "Clone Boost" (branch:) steps, which fails for
pull_request events; update both expressions to pick github.head_ref when
github.event_name == 'pull_request', otherwise github.ref_name, and fall back to
'develop' if neither is present (e.g. use an expression like: ${{
(github.event_name == 'pull_request' && github.head_ref) || github.ref_name ||
'develop' }}). Ensure you update both the ref: in the Clone Capy step and the
branch: in the Clone Boost step.
- Around line 79-86: The Linux workflow is missing the sidebar navigation step
that other jobs include; insert a step named like "Generate sidebar navigation"
(matching the same step used in the other OS jobs) into the sequence between the
"Generate badges" and "Upload coverage artifact" steps so the job runs the same
sidebar/navigation generation script prior to uploading the coverage artifact;
ensure the step uses the same run command or action and any inputs used by the
corresponding step in the other job to keep behavior consistent.
- Around line 431-450: The gcovr invocation in the "Generate gcovr report" step
must supply --gcov-executable on Windows; update the gcovr command in that step
(the gcovr block) to set a gcov path based on RUNNER_OS (e.g., in the shell
before calling gcovr: if [ "${RUNNER_OS}" = "Windows" ]; then
gcov_exe="gcov.exe"; else gcov_exe="gcov"; fi) and pass --gcov-executable
"${gcov_exe}" to the gcovr invocation so Windows runners use gcov.exe while Unix
uses the default.
---
Nitpick comments:
In @.github/workflows/code-coverage.yml:
- Around line 402-403: The cxxflags and ccflags entries add redundant coverage
flags; replace the three flags with the single GCC shorthand by keeping only
"--coverage" for both cxxflags and ccflags (remove "-fprofile-arcs" and
"-ftest-coverage" while leaving any existing "-fprofile-update=atomic" if
desired or remove it if you want exact parity with the macOS job), updating the
entries named cxxflags and ccflags accordingly so the Linux job matches the
macOS job’s simpler instrumentation.
- Around line 544-552: The root gh_pages_dir/index.html generated by the
here-doc lacks a <title>; update the here-doc block that writes
gh_pages_dir/index.html to include a <title>Code Coverage</title> inside the
<head> (i.e., change the <head></head> in the here-doc to <head><title>Code
Coverage</title></head>) so the root index matches the branch pages.
In `@README.md`:
- Around line 3-4: Update the six coverage badge image alt texts that currently
use the generic string "Lines" to platform-specific labels: replace alt="Lines"
with alt="Linux lines", alt="macOS lines", and alt="Windows lines" for the
corresponding gcovr-linux, gcovr-macos, and gcovr-windows badges in both the
master and develop rows; locate the image markdown entries containing the badge
URLs (gcovr-linux/badges/coverage-lines.svg,
gcovr-macos/badges/coverage-lines.svg, gcovr-windows/badges/coverage-lines.svg)
and change their alt attributes accordingly.
| - name: Generate badges | ||
| run: python3 ci-automation/scripts/generate_badges.py gcovr |
There was a problem hiding this comment.
generate_badges.py on Linux is missing the --json gcovr/summary.json flag.
The macOS (line 265) and Windows (line 456) badge-generation steps both pass --json gcovr/summary.json explicitly. The Linux step omits it. If lcov-jenkins-gcc-13.sh --only-gcovr writes the summary JSON to a path the script doesn't default to, badge generation will silently fail or produce incorrect results.
🔧 Suggested fix
- - name: Generate badges
- run: python3 ci-automation/scripts/generate_badges.py gcovr
+ - name: Generate badges
+ run: python3 ci-automation/scripts/generate_badges.py gcovr --json gcovr/summary.json🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/code-coverage.yml around lines 79 - 80, The Linux
badge-generation step calling "python3 ci-automation/scripts/generate_badges.py
gcovr" omits the --json gcovr/summary.json flag, so add the missing flag to that
invocation (make it "generate_badges.py gcovr --json gcovr/summary.json") to
match the macOS and Windows steps; this ensures the generate_badges.py script
receives the explicit summary JSON path produced by lcov-jenkins-gcc-13.sh
--only-gcovr and prevents silent failures or incorrect badges.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #165 +/- ##
===========================================
- Coverage 82.28% 82.02% -0.26%
===========================================
Files 70 70
Lines 5876 5876
===========================================
- Hits 4835 4820 -15
- Misses 1041 1056 +15 see 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
2 participants
Summary by CodeRabbit
Chores
Documentation