On Wed, Jul 29, 2020 at 03:32:16PM +0100, Sorin Sbarnea wrote: > CI/CD is cheap, human work is expensive. > > If you avoid testing it PR, you will allow introduction of changes that break > the master branch. > > For small projects it does not make sense to avoid testing anything before > merge (PR), only for big projects where testing takes many hours and days it > makes sense to use promotion pipelines. > > That is what we do on OpenStack, but for pytest & co, there are no reasons to > optimize testing strategy especially as any regression that slips into master > is likely to be extra load for the project maintainer (as opposed to the PR > OP). It is not uncommon for me to find broken jobs when I propose PR, and > also raise one or two other PRs for fixing those, just to get everything > green before my patch is ready. > > By lower PR testing coverage, you loose the opportunity to spread the > maintenance burden with occasional contributors.
I never said you should not test PRs at all. I only said a periodic check against the pytest master probably shouldn't be part of the checks run against PRs. Quoting myself: > Agreed! Just because the environment exists, it doesn't mean it has to run for > PRs. Similarly, it doesn't make sense to run e.g. linters periodically. > > In other words, run environments with pinned versions for PRs/branches, run an > environment with unpinned (and prerelease/VCS) dependencies periodically. Florian -- m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/
signature.asc
Description: PGP signature
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
