Set threshold for Coveralls failure

[dlech]

Since MicroPython coverage tests have non-deterministic behavior, many lines of code are executed a different number of times in each CI run. Coveralls takes this number into account when calculating the coverage, so often we get "failures" due to variance between runs even though nothing actually changed. Coveralls provides a threshold setting for what constitutes failure. This could be set (or increased if it is already set) to reduce the number of nuisance "failures".

[dpgeorge]

Since MicroPython coverage tests have non-deterministic behavior,

I don't think its non-deterministic, I think it's just that Coveralls does not work properly. Eg:

How can line 192 not be executed if line 193 is? And how can line 202 be executed if lines 198 and 200 are not?

Coveralls provides a threshold setting for what constitutes failure.

It's set to quite a small number so that it catches a single line that is now uncovered by a new PR. This actually used to work in the past, it alerted me a few times when the coverage decreased by 1 or 2 lines.

So:

1. coveralls seems broken
2. setting the threshold too high effectively renders the test useless because it can just gradually get less and less coverage over time (if tests are not written)

Given that, we should probably just remove the coveralls check. Would be great to replace with something that is part of GitHub workflows/actions, and I don't think that is too difficult. Eg I'm already generating this page using lcov daily: https://micropython.org/resources/code-coverage/

[dlech]

Codecov might be an alternative too. I've never used it.

[dpgeorge]

Codecov might be an alternative too.

Thanks for the hint! See #7457.

[dpgeorge]

Switched to Codecov in c940597. Let's see if it's any better. Can easily revert back to Coveralls if needed.

[dpgeorge]

Looks like Codecov has the same issues as Coveralls. So that means there's something wrong with the data generated by lcov as part of the coverage build.