It seems like the prefix of the project path on Github’s CI runners on Windows, eg. D:/a/USER/REPO, does not get removed anymore by codecov when reading the uploaded report.
This started happening after the recent outage and is causing a lot of troube in our repository, as the reports are all incorrect now and the PR checks with certains thresholds/targets are failing because of that. The recent commit on our master branch is also affected by this.
Affected master branch:
Example PR:
streamlink:master ← bastimeyer:tests/mixins/stream_hls/fix-early-writer-close
opened 07:36AM - 09 Oct 20 UTC
This should fix the following issue in #3227:
https://github.com/streamlink/str… eamlink/runs/1227523417?check_suite_focus=true#step:5:257
----
Two issues fixed in one PR (don't squash):
1. Sometimes the writer thread was too fast for the reader thread of the stream_hls test mixin to read, and it closed before the first read occured. The result was an empty read, since the buffer got closed by the writer thread too early. This PR makes the writer thread wait before closing until the reader thread has at least attempted to read once.
2. Currently, Streamlink doesn't wait for the spawned threads of the `ThreadPoolExecutor` to shut down and immediately clears all queued thread pool threads globally. This is not a particularly graceful way to close the writer thread:
https://github.com/streamlink/streamlink/blob/cb5cee6109b98e61f98b42967185a379a4748e0a/src/streamlink/stream/segmented.py#L107-L109
In Python 3.9, the `cancel_futures` parameter was just added to the `ThreadPoolExecutor.shutdown` method, which only clears the queue of the current ThreadPoolExecutor instance:
https://github.com/python/cpython/blame/3.9/Lib/concurrent/futures/thread.py#L210-L229
This can be backported easily, so that the current ungraceful method can be removed. Also setting `wait=True` here will ensure that the writer thread has fully closed. For the HLS tests, this is a needed fix, and for streamlink_cli, I believe this won't make a difference, since it doesn't join the daemon thread anyway, but I'm not sure.
Github actions
codecov-action
cb5cee6109b98e61f98b42967185a379a4748e0a
codecov:
notify:
require_ci_to_pass: true
# wait until at all test runners have uploaded a report (see the test job's build matrix)
# otherwise, coverage failures may be shown while some reports are still missing
after_n_builds: 12
comment:
# this also configures the layout of PR check summaries / comments
layout: "reach, diff, flags, files"
# don't ever let the codecov bot comment on PRs
after_n_builds: 999999999
coverage:
range: "50...100"
precision: 2
round: down
status:
changes: false
patch: false
# split up coverage reports by path
# don't set coverage targets and instead set coverage thresholds
show original
We’re having the same problem on pydantic,
See https://github.com/samuelcolvin/pydantic/issues/1979 .
Codecov team: it would be really great if you could fix this quickly.
tom
October 9, 2020, 5:19pm
3
Hi @bastimeyer and @samuelcolvin , thanks for bringing this up. I’ll update here and we investigate.
tom
October 9, 2020, 5:50pm
4
We have found the issue and made the fix here . We will be deploying shortly.
tom
October 9, 2020, 6:07pm
5
@bastimeyer , @samuelcolvin the fix is now deployed. Please let me know if you’re still experiencing this issue.