Drop the CI job that requests automated tests?

[oliverklee]

I've found the CI job that requests tests coverage for changes in PHP code (introduced in #1342) more of a nuisance: It has blocked merges of changes that did not need any tests (e.g., code cleanup), and I personally would be fine with removing it and requesting tests in human reviews instead where needed.

What do you think, @JakeQZ?

[JakeQZ]

What do you think, @JakeQZ?

I'm inclined to agree. Though for the most part third party contributors are likely to be fixing a bug or adding a feature, for which unit tests would be required. It is mostly only going to be maintainers making changes that do not effect functionality (such as refactoring, resolving static analysis issues, making use of new PHP language features, etc.), though occasionally a contributor may need to provide a refactoring pre-PR.

I had wondered how the CI job would determine that the code changes were substantive enough to require tests. I thought it might be triggered only when a new public class or method was added - that would be quite useful.

[oliverklee]

I had wondered how the CI job would determine that the code changes were substantive enough to require tests.

As far as I understand, the test checker action works like this:

"If a PR changes any file of the corresponding type (in our case. *.php) in the source code directory (in our case, src/), require changes to the tests directory (in our case, test/)."