Adding code coverage report to build#553
Conversation
Codecov Report
@@ Coverage Diff @@
## master #553 +/- ##
=========================================
Coverage ? 37.88%
=========================================
Files ? 216
Lines ? 9006
Branches ? 3516
=========================================
Hits ? 3412
Misses ? 3384
Partials ? 2210Continue to review full report at Codecov.
|
|
Fixes #498 |
|
Is this something we'd could for PRs as well? What is the time overhead like when running those code coverage steps? |
Yes. This will run on PRs. The coverage steps themselves take on the order of 30 seconds. The biggest overhead is that now we build the stack a second time just to collect coverage data, |
mkhansenbot
left a comment
There was a problem hiding this comment.
Looks good to me, thanks for adding this!
.circleci/config.yml
Outdated
| name: Report Code Coverage | ||
| command: | | ||
| export ci_env=`bash <(curl -s https://codecov.io/env)` | ||
| . install/setup.sh |
There was a problem hiding this comment.
Do we need to source the workspace to run codecove?
There was a problem hiding this comment.
I think so, but I'm not 100% sure. It might be that we have to do it because we don't have all the right exec dependencies listed in our package.xml files.
It looks like the CircleCI was missing the run steps to upload the codecove files for PRs, so I added 38bb5fa to try and include that. Though I'm not sure I understand the environment setup codecov needs, so please check that I've invoked it correctly. Travis RP job's codcov upload might overwrite CircleCI upload though, so we may want to pick just one for PRs. |
.circleci/config.yml
Outdated
| @@ -186,6 +199,7 @@ executors: | |||
| working_directory: /opt/nav2_ws | |||
| environment: | |||
| CMAKE_BUILD_TYPE: "Release" | |||
There was a problem hiding this comment.
For a COVERAGE_ENABLED build, it'll need to be CMAKE_BUILD_TYPE=Debug to produce a useful report. With the release optimizations, the coverage data will probably be unusable.
We'll also need to set a token in the CI environment that the upload script uses. See https://codecov.io/gh/ros-planning/navigation2/settings
I believe you have access.
However, before we set that for circle CI, I think we should only upload from either Travis or Circle. Uploading twice for the same PR might be an issue. I was going to see how much of our 1000 minutes we were using before adding more to the CircleCI build. Do you know how to check the amount of time we've used?
There was a problem hiding this comment.
Nevermind. I just noticed you said the exact same thing.
There was a problem hiding this comment.
For a COVERAGE_ENABLED build, it'll need to be CMAKE_BUILD_TYPE=Debug to produce a useful report. With the release optimizations, the coverage data will probably be unusable.
Should we just default to Debug builds for PRs, using a nightly cron on master to build/test both. The cron could have a forked workflow:
- testing with Debug (and thus codecove for master branch)
- testing Release (to make sure at least master is periodically Release tested)
I was going to see how much of our 1000 minutes we were using before adding more to the CircleCI build. Do you know how to check the amount of time we've used?
I can't see this, but org admins should be able to view the stats here:
https://circleci.com/gh/organizations/ros-planning/settings#usage
Although, open source projects (jobs for public repos I presume) shouldn't be affected.
https://discuss.circleci.com/t/has-the-build-minutes-per-month-in-the-free-tier-been-reduced/26399/3
However, before we set that for circle CI, I think we should only upload from either Travis or Circle.
I could comment out the codecov line in Travis to just test out Circleci. Once we merge, circleci config used for PRs would be updated, so we could then profile the added time for codecov steps.
|
I changed the workflow to trigger parallel builds for Release and Debug. I'm not sure if we need to test release on PRs as well, but currently only the debug job includes the command to upload to codecov. We can rework the trigger filter to be whatever combination we'd need, like only testing both on master branch, ect. |
…nterface (ros-navigation#553) * [AdmittanceController] Addintional argument in methods of ControllerInterface * Update admittance_controller.cpp
Basic Info
Adding code coverage generation to the travis build with a report out on Codecov.io.