Description
It looks like the codecov results that get reported in CI are sometimes not a complete aggregation of the different CI matrix entries, which can include the Python 3.8 jobs that have no logs repo present (and run very quickly), and the other jobs that always have the logs repo present (and generally take longer for obvious reasons).
Somewhat speculative, but I believe the problem may be that sometimes i.e., the faster-running non-logs CI entries send their results to codecov server and then codecov immediately issues the report to CI because we have require_ci_to_pass set to false at the top level. You might think that means that the CI would fail if we set it to true, but if you read the docs:
https://docs.codecov.com/docs/codecovyml-reference#codecovrequire_ci_to_pass
Should Codecov wait for all other statuses to pass before sending its status.
There's also documentation and some FAQs on merging reports here:
https://docs.codecov.com/docs/merging-reports
I also don't get why we have two separate entries for require_ci_to_pass at different levels, but SciPy has that as well in their config. Perhaps after_n_builds: 3 might help, to guarantee that there is no report until at least one run with the full suite/logs repo present. codecov settings/orthogonality can be tricky.