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

Find out why coverage dropped when testing with PyPy3.8 #325

Closed
pepoluan opened this issue Dec 16, 2022 · 7 comments
Closed

Find out why coverage dropped when testing with PyPy3.8 #325

pepoluan opened this issue Dec 16, 2022 · 7 comments
Labels
testing Issues/PRs related to the test suite upstream Issues caused by upstream bugs

Comments

@pepoluan
Copy link
Collaborator

When doing fixes/upgrades/enhancements to GitHub CI, I found out that coverage dropped if the Python version was PyPy3.8, necessitating a skip on coverage testing specifically for PyPy3.8

Here's an example: https://github.com/aio-libs/aiosmtpd/actions/runs/3695940538/jobs/6259040475

Strangely, now that I have the time to peruse the full result of the action, it seems to affect only PyPy3.8 on Ubuntu-{18,20}.04 ?

Is it worth it to delve deeper?

@pepoluan
Copy link
Collaborator Author

In commit 5b62b88 I chose to only explicitly exclude the combination of PyPy3.8 + Ubuntu-{18,20}.04.

If test is green I'll just leave it at that and not delve deeper.

@pepoluan
Copy link
Collaborator Author

Update: No, it's not just limited to {18,20}.04

See this: https://github.com/aio-libs/aiosmtpd/actions/runs/3710309144

I think I'll "revert" to the strategy of not doing any coverage testing for PyPy3.8

pepoluan added a commit that referenced this issue Dec 16, 2022
@pepoluan pepoluan added the testing Issues/PRs related to the test suite label Dec 21, 2022
@pepoluan
Copy link
Collaborator Author

This will still need to be investigated, though. So I'm keeping this issue alive.

@pepoluan
Copy link
Collaborator Author

After some investigation, it's because PyPy3.8 changes some decorator behavior since v7.3.10.

This is described in nedbat/coveragepy#1515

Until a new coverage.py is released (>7.0.1) there is nothing we can do.

The new behavior has been accounted for by coverage.py for PyPy>=3.9, though, so when GHCI finally adds PyPy3.9 runner, we should be good.

Therefore I'm going to 'ignore' this issue for now until a new coverage.py version that accounts for v7.3.10's behavior change is released.

@pepoluan pepoluan added the upstream Issues caused by upstream bugs label Dec 29, 2022
@waynew
Copy link
Collaborator

waynew commented Jan 2, 2023

👍 seems reasonable to me

@pepoluan
Copy link
Collaborator Author

pepoluan commented Jan 4, 2023

Aaaand 7.0.3 has been released several hours ago (at time of my commenting)

I'll revisit this in a couple of days.

@pepoluan
Copy link
Collaborator Author

Tried the latest coverage-7.0.5 and it still fails if the test is running on PyPy3.8 7.3.10-final, but works on PyPy3.8 7.3.11-final.

7.3.10-final is apparently the version that gets installed on MacOS-11, MacOS-12, and Windows-2019. Other OSes in the GitHub Action runners installs 7.3.11-final.

Because we have successfully run the tests on PyPy3.9 anyways, I think it's just too much effort to tweak the tests so that coverage is 100% on PyPy3.8. Besides, the 'canonical' coverage test is based on CPython 3.8 on Ubuntu 20.04 anyways.

Therefore I will let the current GHCI config (no coverage for PyPy3.8) to stand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
testing Issues/PRs related to the test suite upstream Issues caused by upstream bugs
Projects
None yet
Development

No branches or pull requests

2 participants