Add Coverage workflow #623
Conversation
|
if it's a pain to run PyPy tests under coverage, I think it would be fine to do the pypy tests as a separate CI job that aren't run under coverage. None of our code is currently PyPy-specific (we had a workaround for a PyPy bug for a while but it was a tiny branch of code). |
|
Could you fix the pre-commit failures? |
|
According to https://docs.github.com/actions/how-tos/security-for-github-actions/security-guides/automatic-token-authentication, a PR from a fork can never have write access (expect the repo itself). A relevant bit:
Maintainers note from the action on the error: https://github.com/marocchino/sticky-pull-request-comment/tree/v2/#error-resource-not-accessible-by-integration
The alternative is to provide a |
Added a coverage workflow (resolves: #520).
Currently the logic is to upload one coverage file from each version test.
pip install coverage&coverage -m unittestA crucial point about this workflow is that it installs and runs the test with
coverage -m unittestand notpython -m unittestanymore.coveragedoes (currently) not installtyping_extensionsso I think that is a safepip install(at the moment). I tried to add a weak test that assures thattyping_extensions.__file__is indeed the one insrc/and notsite-packages, but that test fails on the pypi installationDo you prefer any changes here? e.g. run first with
pythonwhen install and run again with coverage?Does anyone know why the pypy 3.9 and 3.10 tests fail here? Some kind of code leakage, missing monkeypatch?
EDIT: