codecov-action
codecov-action copied to clipboard
v2 not finding python .coverage file
Hi all,
I have a multi-language repository and for some reason, the v2 action can't find the python coverage reports. Here's my setup:
- Each language is run separately as part of a matrix of the test job = they don't influence each other
- All tests are run inside containers that have volume binds to
./temp, they put the coverage reports there
Here's how I invoke the action:
- name: Upload coverage to codecov
if: ${{ always() }}
uses: codecov/codecov-action@v2
with:
flags: integration
fail_ci_if_error: true
directory: temp/
The exact error message is this:
2021-11-16T15:16:35.0606077Z [2021-11-16T15:16:35.060Z] ['error'] There was an error running the uploader: No coverage files located, please try use `-f`, or change the project root with `-R`
Note that I specified the temp/ folder containing the coverage reports. I use the same bind clause for all languages, meaning that their output is put into the same folder (though on machines since they are part of different matrix entries, thus they don't interfere with each other). I know that this directory is correct because it is working just fine for my JS tests, which put their test output in there, too....
I've also checked the output by adding the following step just before calling the codecov action:
- name: Debug coverage reports
run: ls -al temp
The output I get for this is:
2021-11-16T15:02:33.0480570Z ##[group]Run ls -al temp
2021-11-16T15:02:33.0481454Z ls -al temp
2021-11-16T15:02:33.0540232Z shell: /usr/bin/bash -e {0}
2021-11-16T15:02:33.0541138Z ##[endgroup]
2021-11-16T15:02:33.0678054Z total 60
2021-11-16T15:02:33.0680122Z drwxr-xr-x 2 runner docker 4096 Nov 16 15:02 .
2021-11-16T15:02:33.0681171Z drwxr-xr-x 13 runner docker 4096 Nov 16 15:01 ..
2021-11-16T15:02:33.0682029Z -rw-r--r-- 1 root root 53248 Nov 16 15:02 .coverage
So the coverage file is definitely there.
Now why does this work for my JS reports, but not for the .coverage file generated by my python tests?
- The output for the JS reports is a file like this:
coverage/lcov.info - The output for the python reports is a file like this:
.coverage(I've also tried moving it into acoveragesubdirectory, to mimic the structure by the JS reports)
As a workaround, does running coverage xml help?
But see also https://github.com/codecov/codecov-action/issues/456 where it's unclear if that's now necessary with v2 or not...
Yes, that workaround helps.
So the thing is that with v1, it used to work with .coverage (most likely due to what is mentioned in #456 regarding the bash uploader calling coveragexml to do the xml conversion for us), so this is definitely a breaking change in v2...
Regarding documentation:
- https://about.codecov.io/language/python/ makes no mention of the standard
coverageoutput needing to be converted into some other format - https://github.com/codecov/example-python/commits/master/README.md suggests that it is a change that was introduced at some point in the near past - notably on Sep 10, the example was adjusted to using the v2 uploader, and there are two separate PRs from forks after that to add the xml part to the example
That's also why I specified v2 in the title of this issue - though it seems that I forgot to mention that it used to work with v1 without converting the output to some other format.
So my suggestions are to either:
- add that additional call that the bash uploader used to do to not require users to make an additional call
- if there is a conscious decision to drop that support, it needs to be properly documented, both as a breaking change for those migration from v1, as well as for new users of codecov in general that the server is unable to handle the default
.coveragereports
Interestingly, I am still using v1 and have my coverage report stored in .coverage. Here is my configuration.
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v1
with:
token: ${{secrets.CODECOV_TOKEN}}
flags: unittests
verbose: false
It used to be located automatically but I had to add files: .coverage to get it working again. It looks like this issue affects both versions
I'm going to close this out as the answer is to run coverage xml