this has been bugging me for quite some time but I never took the time to really investigate what the root cause is. Also it happened to me that coveralls shows files that have a changed test coverage although the classes are not touched by the tests.
As a reviewer I am not that strict when I see that github checks failed because of a slight decrease in test coverage. We could go around this by adapting the coveralls settings to not fail if coverage decreased for example by 0.1, but this also seems like a workaround (the root cause).
If you have time to dig deeper, I would be happy to help and also learn
Sure @teleivo I Would like to further research on the issue. Will let you know if I find anything.
I found out that there is a problem with coveralls coverage algorithm. It seems they’re using a incorrect base commit which results in incorrect increase/decrease coverage in pull requests. You can find some information related to the problem here.
I don’t have access to coveralls. Can someone share the user with me, or grant me access, or anything?
But that issue you linked in theory has been already closed 2 years ago?
Coverage decreased (-0.01%) to 58.605% when pulling 5cf0e62 on IsurangaPerera:TRUNK-4872 into dee1e8f on openmrs:master.
https://coveralls.io/jobs/34765808 -> dee1e8f
The master commit was correct, in theory.
It seems pretty odd that a ticket which only adds unit tests have a decrease in coverage. Sounds super wrong. I agree with @teleivo that it should not block merging the PR, but I don’t understand what’s happening there.