Set coverage limits so we do not have current failures

[AlanCoding]

SUMMARY

We have 2 checks always failing, and I'd rather them not.

@codecov
codecov/project/lib — 79.67% (target 100.00%)
[Details](https://github.com/ansible/awx/pull/15625/checks?check_run_id=32807836738)
@codecov
codecov/project/tests — 97.76% (target 100.00%)
[Details](https://github.com/ansible/awx/pull/15625/checks?check_run_id=32807837299)

Ping @webknjaz

ISSUE TYPE

• Bug, Docs Fix or other nominal change

COMPONENT NAME

• API

[webknjaz]

Agreed. This does create friction for the contributors.

@AlanCoding could you also make said checks required after merging this PR? And make codecov/patch/pytest and codecov/patch required, too. Maybe even instead of their project counterparts — the patch checks are more stable because they only take into account the changed lines of code, while there may be indirect coverage changes in places that are not modified in a PR, which creates confusion for people, when the project coverage isn't kept at 100%.

Talking about 100% — it's a good idea to have it at some point in the future, but it would require better configuration for excluding the lines that are never going to be covered (exclude_also in the config + inline # pragma: no cover across the codebase). This is obviously out of the scope of this PR, but I wanted to throw the idea out there so it's documented.

[webknjaz]

We should also update after_n_builds: 5 to after_n_builds: 6 at the top. I noticed that Codecov is starting to report the coverage early, before the last upload happens. It's then updated with that upload later on, but could be confusing to people. So I like matching this to the number of the expected uploads, making Codecov report the check results only after it has processed all the data points.

This would eliminate friction related to displaying a coverage drop and a red cross mark temporarily during the PR lifetime.

[AlanCoding]

could you also make said checks required after merging this PR?

Yeah, probably good to do, but I believe this is a github repo setting as opposed to a code change, so it's an administrative action after merging, like you say.

I started on this because, with #15625, that should allow checks to pass again.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud