Instead of trying to handle unittest-async functions in pytest_pyfunc_call,
let the unittest framework handle them instead.
This lets us remove the hack in pytest_pyfunc_call, with the upside that
we should support any unittest-async based framework.
Also included 'asynctest' as test dependency for py37-twisted, and renamed
'twisted' to 'unittestextras' to better reflect that we install 'twisted' and
'asynctest' now.
This also fixes the problem of cleanUp functions not being properly called
for async functions.
Fix#7110Fix#6924
twisted started to use `attr.s(eq)` argument which was added recently,
so it fails with oldattrs. One of the CI jobs ran twisted and oldattrs
together, so it started to fail.
Move the twisted code to be covered by another job, and remove it from
the job with the oldattrs.
* Explicitly state on the PR template that we can squash commits
This way we don't need to ask every time, and users who for some reason
would not like us to squash their commits can explicitly state so.
This often might be causing for jobs to take longer than 10 minutes,
which is a timeout Codecov uses to wait for successful CI.
Also it is good in general to have CI finish faster, of course.
This overwrites the `codecov.yml` file in the root of the repository with
`codecov-upstream.yml` file (which contains the code-cov token)´, so PRs
and branches on the repository can upload coverage.
Suggestion from here:
https://github.com/pytest-dev/pytest/pull/6421#issuecomment-571934112
Security concerns: the token might be misused, but only to upload bogus coverage
to `codecov.io`, so the team believe this is harmless. If we decide to fallback
from this decision , we just need to revoke the token.
Related to #6369
This includes our current full matrix (windows, linux and macos), for evaluting
purposes.
We should disconsider failures when evaluating PRs.
TODO:
- deploy
- coverage
- github release notes
Even with the above missing, I still believe it would be nice to merge
this and have GitHub actions working in parallel so we can evaluate performance
and usability from now on.
This creates a separate section from 'features' for small changes which
don't usually require user intervention, such as:
* Human readable session duration
* New junitxml fields
* Improved colors in terminal
* etc.
The idea is to better match user expectations about new actual
features in the "Features" section of the changelog.
This streamlines the PR template text and adds a more in-depth explanation
about how the changelog entries work because this topic is a common source of
confusion:
- How to name the files.
- Which formatting to use (people in general assume it is Markdown).
- Recommend adding `.rst` extension to changelog files to help with the
above (`towncrier` doesn't care).
This was heavily inspired by the excellent python-trio/trio docs.
Ran Benita
Anthony Sottile
Bruno Oliveira
Bruno Oliveira
Daniel Hahler
Hugo
Florian Bruhin
Florian Bruhin
Ronny Pfannschmidt
Dave Hunt