James Kessler

@Panaetius I continually re-confuse myself when looking into similar issues, so, if you don't mind, please refer to [this comment ](https://github.com/TheKevJames/coveralls-python/issues/252#issuecomment-823517551), where I attempt to clarify the distinctions at play...

@aenachescu I agree. Relevant lines should be considered relevant in all jobs, but only if all things remain equal, which is to say, if the same coverage library is being...

Hi @aenachescu, thanks for the details. So, at a high level, I'm afraid I need to kick the issue back to you. In other words, there's nothing specific to Coveralls...

@aenachescu aha. No, I don't have that expertise, but that was going to be my guess, that somehow the different compilers render different lines of the original source relevant /...

Hi @vtjnash. So at this point, I noticed that you've run at least one more build against [that PR](https://github.com/vtjnash/Pidfile.jl/pull/11) and, as designed, the latest PR Comment replaced the previous one....

> Looking at codecov on the same commit, and examining the build logs for individual jobs to see that 92% is overestimating the total (missing some lines that are only...

First, your CI config looks fine. Thanks for sharing it. > Yes, I am just guessing there at why it seems to agree exactly with the last build, but disagree...

P.S. I tried it on two more of your PR builds (the last build for each PR): - https://coveralls.io/builds/44414158 (for PR 9) - https://coveralls.io/builds/37426114 (for PR 7) And aggregate coverage...

Hi, @vtjnash. I can't find any more cases of PR builds that display the behavior where overall coverage matches the coverage of the last job. For instance, this [build for...

Got it. Yeah, I see the repo is stable and updates are infrequent. Well, we can keep this open, or you can re-open it if it happens again. Or email...