-
Notifications
You must be signed in to change notification settings - Fork 10
Add C++ coverage configuration and workflow #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- Add coverage_report.yml with LCOV/HTML report generation - Configure Bazel coverage flags in .bazelrc
License Check Results🚀 The license check job ran with the Bazel command: bazel run //:license-checkStatus: Click to expand output |
|
The created documentation from the pull request is available at: docu-html |
- LLVM flags (-mllvm, -runtime-counter-relocation) are incompatible with GCC - Comment them out to fix CI coverage build failures - Can be uncommented when using LLVM/Clang toolchain
- LLVM flags (-mllvm, -runtime-counter-relocation) are incompatible with GCC - Comment them out to fix CI coverage build failures - Can be uncommented when using LLVM/Clang toolchain
Remove LLVM-specific flags and instrumentation filter that were causing empty coverage reports. Use only the three baselibs flags: - coverage --features=coverage - coverage --combined_report=lcov - coverage --cache_test_results=no Fixes: SWP-240231
8449a01 to
10dcabb
Compare
- Add --ignore-errors empty to genhtml to handle sparse coverage
- Add file size check before running genhtml - Add more ignore-errors flags
PiotrKorkus
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you took some of the settings from baselibs but baselibs uses different toolchain.
Please double check which gcc toolchain is correct.
Coverage data should never be empty.
Also Rust and C++ coverages should be calculated separately.
| else | ||
| echo "Coverage report is empty, skipping HTML generation" | ||
| mkdir -p cpp_coverage | ||
| echo "<html><body><h1>No coverage data available</h1></body></html>" > cpp_coverage/index.html | ||
| fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should never be empty. Empty = expected fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
bd555b3 to
34bbd76
Compare
Thanks for pointing this out! I’ve added score_bazel_cpp_toolchains (the same toolchain used in baselibs), which properly supports Bazel coverage. Coverage data is now generated correctly and is no longer empty |
|
|
||
| - name: Run Bazel Coverage | ||
| run: | | ||
| bazel coverage --config=blcov-x86_64-linux -- //score/... //tests/... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why run //tests/... when you have instrumentation filter on //score?
| coverage --instrumentation_filter="^//score[/:]" | ||
|
|
||
| # Coverage configuration | ||
| build:blcov-x86_64-linux --incompatible_strict_action_env |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bl stands for baselibs
| sudo apt-get install -y lcov | ||
| - name: Setup Bazel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please use consistent new line formatting
| gcc_cpp = use_extension("@score_bazel_cpp_toolchains//extensions:gcc.bzl", "gcc", dev_dependency = True) | ||
| gcc_cpp.toolchain( | ||
| name = "score_gcc_x86_64_toolchain", | ||
| target_cpu = "x86_64", | ||
| target_os = "linux", | ||
| use_default_package = True, | ||
| version = "12.2.0", | ||
| ) | ||
| use_repo(gcc_cpp, "score_gcc_x86_64_toolchain") | ||
|
|
||
| gcc = use_extension("@score_toolchains_gcc//extentions:gcc.bzl", "gcc", dev_dependency = True) | ||
| gcc.toolchain( | ||
| sha256 = "457f5f20f57528033cb840d708b507050d711ae93e009388847e113b11bf3600", | ||
| strip_prefix = "x86_64-unknown-linux-gnu", | ||
| url = "https://github.com/eclipse-score/toolchains_gcc_packages/releases/download/0.0.1/x86_64-unknown-linux-gnu_gcc12.tar.gz", | ||
| ) | ||
| use_repo(gcc, "gcc_toolchain", "gcc_toolchain_gcc") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think those 2 shouldn't coexist or only one common config should be used for build, test and coverage for x86 linux
| bazel_dep(name = "score_platform", version = "0.5.1", dev_dependency = True) # This is main score repo | ||
|
|
||
| # Toolchains and extensions | ||
| bazel_dep(name = "score_bazel_cpp_toolchains", version = "0.2.0", dev_dependency = True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you use this, you should kick out score_toolchains_gcc and score_toolchains_qnx.
I suggest to do it in a separate PR and do not mix up with the coverage workflow.
| # SPDX-License-Identifier: Apache-2.0 | ||
| # ******************************************************************************* | ||
|
|
||
| name: Code Coverage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a copy-paste from baselibs. I'm actually considering to have it reusable via cicd_workflows, but I'm not sure this workflow is in the right shape to push it there.
Ideally, if it's to be reusable, it should support not only C++, but also Rust and maybe Python.
And for Rust, I'm wondering how it will mix up with the Ferrocene toolchain. @pawelrutkaq, does the rust coverage also rely on bazel coverage?
Notes for Reviewer
Pre-Review Checklist for the PR Author
Checklist for the PR Reviewer
Post-review Checklist for the PR Author
References
Closes #