Skip to content
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

Take the highest coverage count for a single line #102

Merged
merged 1 commit into from
Jul 2, 2017

Conversation

Kjir
Copy link
Contributor

@Kjir Kjir commented Jun 11, 2017

In some cases the call to erlang's cover.analyse/3 will return more than
one result for the same line. Usually the coverage count is the same,
but in some cases (e.g. with schema definitions in an Ecto model) the
coverage count can alternate between different values, like 1 and 0, and
the line might be marked as covered or not depending on the order of
these results.

Investigations did not lead to a definite answer as to why this is
happening, but with this fix we will at least take the greatest coverage
count, instead of the latest, as the value for our report.

Fixes #84

@Kjir
Copy link
Contributor Author

Kjir commented Jun 11, 2017

This might also affect the problems reported in #90 and #66

@coveralls
Copy link

coveralls commented Jun 11, 2017

Coverage Status

Coverage remained the same at 92.236% when pulling e6eace9 on Kjir:fix/coverage_changes into 1a3e980 on parroty:master.

In some cases the call to erlang's cover.analyse/3 will return more than
one result for the same line. Usually the coverage count is the same,
but in some cases (e.g. with schema definitions in an Ecto model) the
coverage count can alternate between different values, like 1 and 0, and
the line might be marked as covered or not depending on the order of
these results.

Investigations did not lead to a definite answer as to why this is
happening, but with this fix we will at least take the greatest coverage
count, instead of the latest, as the value for our report.

Fixes parroty#84
@coveralls
Copy link

coveralls commented Jun 11, 2017

Coverage Status

Coverage remained the same at 92.236% when pulling 8dbe15d on Kjir:fix/coverage_changes into 1a3e980 on parroty:master.

@parroty parroty merged commit c3821c4 into parroty:master Jul 2, 2017
@parroty
Copy link
Owner

parroty commented Jul 2, 2017

Thanks for addressing this issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Coverage changes when running coveralls vs coveralls.html
3 participants