-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Generate C++ coverage reports too! #2314
Conversation
@@ -9,7 +9,10 @@ | |||
"license": "MIT", | |||
"scripts": { | |||
"rebuild": "lerna run --stream rebuild", | |||
"coverage": "nyc report --reporter=text-lcov > coverage.lcov && codecov", |
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.
nyc report --reporter=text-lcov > coverage.lcov
is redundant with nyc --reporter lcovonly mocha
(npm test
).
@reconbot any thoughts? |
@@ -1,19 +1,21 @@ | |||
name: Test / Lint | |||
on: | |||
push: | |||
pull_request: |
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.
The test-merge.yml
workflow was basically identical to this one. I thought might as well de-dupe. Happy to not do this if you prefer.
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.
yeah lets merge that in another pr and rebase this one
test: | ||
runs-on: ${{ matrix.config.os }} | ||
strategy: | ||
fail-fast: false |
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 say might as well let other tests finish even if there is an error. Cover more systems faster.
packages/bindings/binding.gyp
Outdated
{ | ||
'cflags+': ['--coverage'], | ||
'link_settings': {'libraries+': ['-lgcov']}, | ||
'xcode_settings': { |
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've seen others put macOS conditions around xcode_settings
but that doesn't seem to be necessary as far as I've seen.
packages/bindings/binding.gyp
Outdated
'GCC_GENERATE_TEST_COVERAGE_FILES': ['YES'], | ||
'GCC_INSTRUMENT_PROGRAM_FLOW_ARCS': ['YES'], | ||
'OTHER_CFLAGS+': ['-fprofile-arcs -ftest-coverage'], | ||
'OTHER_LDFLAGS+': [ | ||
'-fprofile-arcs -ftest-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.
I've tested without each setting individually. Theses all seem to be necessary instead of the one --coverage
GCC flag.
Way to think different Xcode 😉
I like it! I haven't had time to do a proper review |
Well, it all seems to work! I bet some things could be cleaned up a bit but it all seems to be there. |
Hi @cinderblock I agree and am super keen to expand the test coverage and visibility. Sorry, other than a cursory glance at the coverage report output, I haven't had chance to take a closer look yet. I was a little surprised that the platform specific files showed different levels of coverage for similar functionality, but I guess some of this could be down to the different tooling per platform. Overall I don't think this change should present much in the way of risk to any production users, and will help dev and test in the long term. I know @reconbot is very busy at the moment, but am sure he will help to get this included when he gets some time. |
No worries. I know how life can be. Just don't want this to fall by the wayside. I would relish some thoughts on the new Of note, I haven't tried running these tests with an Arduino (or equivalent) attached. That would almost certainly significantly affect coverage for various platforms. It might be worth figuring out how to regularly run these tests with either a virtual (loopback) COM port (that's all the Arduino test code does anyway) or setting up a custom action runner just for this repo that has the dedicated hardware attached so that anyone can more easily run the full suite of tests. Related, we might want to make the codecov token a proper secret. As it stands, anyone can add a report to codecov. Notice I accidentally did this running tests on my personal machine: |
This has been my dream for years, we just need a loopback serialport. |
package.json
Outdated
@@ -40,6 +46,7 @@ | |||
"lerna": "^3.22.1", | |||
"mocha": "^8.3.0", | |||
"node-abi": "^3.0.0", | |||
"npm": "^7.23.0", |
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?
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.
Good question.This was because both of the Windows coverage tools I chose to use could not find npm.cmd
on the path (or something like that).
I just started a branch to try without this explicitly: https://github.com/cinderblock/node-serialport/actions/runs/1314282300
You can see the Windows builds failing because:
[...] Error: Cannot find module 'D:\a\node-serialport\node-serialport\node_modules\npm\bin\npm-cli.js' [...]
We could probably solve this problem in an alternate way, but my initial goal was to get it working.
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.
One simple alternative would be to add a specific npm install npm@7
step to the Windows workflows.
It works: https://github.com/cinderblock/node-serialport/actions/runs/1314333987
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.
@reconbot would you prefer to not soil the devDependencies
? I can merge the npm i npm
step into this PR which fixes this problem. Just means that anyone that wants to run coverage tests on their Windows machines will need to install npm locally. That being said, all platforms need some extra tools installed for this all to work, so maybe this isn't a big deal.
Alternatively, I bet someone could fix the underlying problem with the Windows paths if they were feeling more ambitious than I am at the moment.
Some macOS updates broke the I also decided to include a change that splits the different OS tests up into fully separate jobs. This makes it a little more readable when following the jobs. We just need to remember to edit all 3 jobs for any test changes. Ultimately, I made this change because of loopback testing plans (#2327) and the assumption that each OS would have even more differences in their respective test environments. |
@cinderblock I've definitely messed up your pr with the introduction of #2384 I want to apologize for that. But I do hope it will a bunch easier to maintain the bindings in a separate repository. I'm game for helping move all this over there. |
This makes sense! I think I'll have time to take a look at moving things over sometime this weekend. Does this have implications for my other pending PRs too? |
This need to be moved to https://github.com/serialport/bindings-cpp |
Coverage tests are wonderful.
This PR adds support for running coverage tests on this package's C++ sources alongside JavaScript's!
Before
After
Update: codecov broke this image!
![After C++ coverage tracking](https://camo.githubusercontent.com/983f4213a6a17f2eb41f60864b644669e92e46d3336f027653b5c165641bc2f0/68747470733a2f2f636f6465636f762e696f2f67682f73657269616c706f72742f6e6f64652d73657269616c706f72742f636f6d6d69742f333362633234303165643261393631316435363432616332333732653534633533643637643662332f6772617068732f696369636c652e737667)
Platforms & Issues
Initially, I'd like to get coverage reports working on Linux and macOS. Windows looks like it will be a little more involved and could be added after initial merging of this PR.
libgcov
libgcov
correctlyMSBuild.exe
'sgcov
equivalent: OpenCppCoveragecodedev
can read -cobertura
✔️package.json#scripts
and update workflowsmacOS
Thoughts on the "correct" way to make coverage reports on macOS would be appreciated. While it works, it could probably be improved.
On Linux,
apt install -y gcc
also installslibgcov.a
(via dependencylibgcc-9-dev:amd64: /usr/lib/gcc/x86_64-linux-gnu/9/libgcov.a
). I've tried installinggcovr
andgcc
withbrew
to see if they provide the missing libraries to no avail.A CI test shows thatlibgcov.a
is available on the system. So maybe it's just anLD_LIBRARY_PATH
setting that needs to be set inbindings.gyp
?Note: the above was run after
brew install gcc
, which probably isn't necessary and probably added a few of these.Update 1
Adding
-L /usr/local/lib/gcc/9/gcc/x86_64-apple-darwin19/9.4.0
to the linker seems to have gotten it to compile on macOS, but when I run it, nogcda
files seem to be generated... https://github.com/cinderblock/node-serialport/runs/3528420934?check_suite_focus=trueUpdate 2
Found a minimally working setup. Some improvements could probably be made.
Windows
As for coverage tests on Windows, I'm not sure where to start. I'm sure there is an equivalent to
gcc
'sgcov
but I haven't had the time to look yet.Update 1
Some possibly helpful tools/links:
Update 2
CPPCoverage is running, but not generating coverage information yet for some reason.
Update 3
OpenCppCoverage works!
Time to format the data in a way that codecov likes and then package this up into the branch!