Version 2.1.3 fails to find gcov files

[pganssle]

Recently codecov stopped uploading my C code coverage on a Python C extension I have written.

In this job, tox is using codecov==2.1.1, and the upload succeeds.

In this job, tox is using codecov==2.1.3 and I see the following error:

==> Detecting CI provider
  -> Got branch from git/hg
  -> Got sha from git/hg
==> Preparing upload
==> Processing gcov (disable by -X gcov)
    Executing gcov (gcov -pb  .../zoneinfo/.tox/gcov/coverage/build/temp.linux-x86_64-3.8/lib/zoneinfo_module.gcno)
    Error running `gcov -pb  .../zoneinfo/.tox/gcov/coverage/build/temp.linux-x86_64-3.8/lib/zoneinfo_module.gcno`: 
        [Errno 2] No such file or directory: 'gcov -pb  .../zoneinfo/.tox/gcov/coverage/build/temp.linux-x86_64-3.8/lib/zoneinfo_module.gcno'
Error: 'NoneType' object has no attribute 'replace'

(I've modified this slightly to make it a bit easier to read by shortening some paths and breaking up one extra long line).

Unfortunately I don't have time to create a minimal reproducer, but if you clone the zoneinfo repository and run tox -e gcov, that should generate the coverage files, and I'm using scripts/upload_codecov.py to upload the coverage files — it is just a script that finds the XML file output that gcovr emits, and passes that to codecov -f.

I'm guessing #167 is the culprit.

[nmoinvaz]

I do notice that it uses three dots ...

[pganssle]

@nmoinvaz That's actually part of the "slight modifications" 😅, anywhere you see the three dots, replace it with /home/runner/work/zoneinfo.

(I also noticed that my original link was not a "permalink" and changed when I pushed a new fix to the PR, I've now updated it to be a permalink).

[nmoinvaz]

I think this might be fixed with the latest master branch since it no longer uses find command: 65d596e. I recommend testing some how with master if you can.

[pganssle]

@nmoinvaz No, I'm pretty sure that's the commit that broke codecov. It works fine with the latest version that uses the find command (version 2.1.1 — confirmed by pinning this in my codecov tox environment).

[nmoinvaz]

I see the version numbers on Pypi are different than in git.

[drazisil]

If that broke it, I'm going to to need to rollback, unless you can somehow test this @nmoinvaz ?

[nmoinvaz]

Ok I will take a look at it

[pganssle]

I see the version numbers on Pypi are different than in git.

See #256

[nmoinvaz]

I was able to reproduce. I have two commits that should help. Please give them a shot.

[nmoinvaz]

This should be resolved now.

[thomasrockhu]

Fixed via #263 and released in 2.1.4