In some of the pull requests, when CodeCov compares the coverage to display the change, it fails with the message “No report found to compare against”.
When I’m opening the “Compare” link, I see that the commit it’s trying to compare to is actually a commit inside the pull request (not the one I expect it to compare to) - and in this case, that commit doesn’t have a coverage report because the tests failed.
The actual problem here is that sometimes CodeCov chooses the wrong commit to compare to for coverage diff.
Is there any way to tell CodeCov to select the last commit that existed when I’ve created the branch, instead of choosing a commit from inside the branch?
** Important to say that most of the times it works (even in cases where I have more than 1 commit in the PR)
Using the CodeCov website
I’m using GitHub, CircleCI, and the code is written in NodeJS.
If you are using the bash uploader, you can use the
-N flag to tell us which commit we should use as the base. This i indeed usefull when we guess the wrong base commit.
Let me know if that helps, please.
Thanks for the answer!
The coverage report is uploaded automatically from CircleCI (using the codecov npm package), so I’m not sure I can do it (I don’t know how to make CircleCI detect the correct commit).
Are there any other ways I can fix it?
Do you have any idea what causes the wrong base-commit detection?
Can you tell me how the base commit is selected? (maybe I could figure out why it fails only some of the times)
I apologize, there was some confusion about how
-N works, including myself, so I’ve given out some bad information.
-N flag allows you to set the
parent commit, not the
base commit, as I believed. This means it’s not helpful in overriding our automatic PR
base picking system.
I believe the ability to override this is a feature request at this point, I am double-checking with product and engineering to see if there is a current way about this.
The way the base picking works is we query the GitHub API for the PR and look at the results for base. This usually returns a single commit, but in some cases after merge master or other branches, it will return more then one. Since we have no what of knowing which is the better one, we currently select the first commit in the results as the base. In some cases this is not what the customer expects.
We are investigating if there are better ways to handle this.
I hope this new feature will be implemented soon.
Thanks for the information and for you assistance