-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
coverage.nodejs.org misreporting #19912
Comments
/cc @nodejs/build @mhdawson |
9th: https://ci.nodejs.org/job/node-test-commit-linux-coverage/600/nodes=benchmark/console Does the output help? it has %'s that match what we're seeing on the table. Maybe we just added a ton of code yesterday and didn't catch up with enough new tests ... |
Those look really useful, thanks. I had found these: I noticed from the job status pages there that job 601 took just 16 mins instead of the usual ~31 mins. |
I reviewed the diff of the two outputs. Aside from the obvious size difference (601 is a shorter log), there are fewer files covered and the coverage for each file is generally worse. It seems to point towards some missing files (both from the test suite and the source files). Is it possible to re-run the job on the CI server? |
maybe we just wait for today's run and see how it goes, perhaps we should delete yesterday's record if it's a simple anomaly |
Today's run has the same numbers as yesterdays .. something's up with the codebase I think. |
Trying to repro the issue locally is proving difficult. I'm not familiar with the codebase and build setup so any pointers appreciated. I found some commands in the build repo but I can't confirm that these are the same as used by
The above fails locally (macOS 10.13.4) with the following error: |
These are the commits between the last known good and the first known failure: The OpenSSL changes look like a sensible suspect, there were some CI failures that have already been reviewed and discounted #19794 (comment) but it might be worth a second look? |
@nodejs/testing |
Looking at the console outputs, it seems like the issue is that
|
(i.e. this points to #19524 being at fault for this) |
Taking the source code of a function and running it in another context does not play well with coverage instrumentation. For now, do the simple thing and just write the source code as a string literal. Fixes: nodejs#19912 Refs: nodejs#19524
Aaand https://coverage.nodejs.org/ is back to normal! 🎉 |
Taking the source code of a function and running it in another context does not play well with coverage instrumentation. For now, do the simple thing and just write the source code as a string literal. Fixes: #19912 Refs: #19524 PR-URL: #20035 Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Trivikram Kamat <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
https://coverage.nodejs.org/ is reporting a significant drop in code coverage in the most recent nightly.
JS Coverage: 94.42% -> 28.80%
C++ Coverage: 92.50% -> 31.10%
Note that my local coverage results seem OK so this looks like a build / job failure.
The text was updated successfully, but these errors were encountered: