search

codecov / codecov-python

Python report uploader for Codecov
https://codecov.io
Apache License 2.0
185 stars 139 forks source link

tool does not respect fixes #318

Closed williamcroberts closed 3 years ago

williamcroberts commented 3 years ago

As far as I can tell the tool does not respect the fixes in the codecov.yml file. Theirs no reference to the fixes key in the YAML file in the code, and seems to not be doing anything locally. I walked through it with a debugger and don't see any spot where it does that.

thomasrockhu commented 3 years ago

@williamcroberts can you open a ticket in our community boards, so I can dig into what might be happening?

williamcroberts commented 3 years ago

Done:

I dunno what moving it over there does, likely just moved it into a black hole.

thomasrockhu commented 3 years ago

@williamcroberts yikes, I'm that black hole. I updated on the ticket, but could you provide a commit SHA of this happening?

williamcroberts commented 3 years ago

@williamcroberts yikes, I'm that black hole. I updated on the ticket, but could you provide a commit SHA of this happening?

I ran all the tools locally, so I could debug them. Can you point to a test in the bash-uploader or python scripts where the"path-fix" feature is tested? I can't find any reference to it.

williamcroberts commented 3 years ago

I'm using the master tip of codecov python and bash tools. Various uploads to the tpm2-pytss project failed, so I replicated everythign locally to debug, which is when I discovered the paths not lining up and trying to do a path fix. If you just look at the python tool:

You should see a regex grabbing the fixes field and applying a fixup to the code paths in the coverage report. I have some changes locally to codecov-python to implement this, but its not will tested.

thomasrockhu commented 3 years ago

@williamcroberts path fixing is handled server-side. I asked for a commit SHA so I could see what was happening for your particular case.

williamcroberts commented 3 years ago

@williamcroberts path fixing is handled server-side. I asked for a commit SHA so I could see what was happening for your particular case.

That explains that. I unfortunately force-pushed. But I can get a branch and revert the change and redo it so we can get some debugging. Is their anyway to introspect what the server is doing?

williamcroberts commented 3 years ago

@thomasrockhu I created a branch with the older method that was failing, ill post back with details when it's done:

thomasrockhu commented 3 years ago

Is their anyway to introspect what the server is doing?

Unfortunately not in a public way. I'll make a note to the product team to make this process easier and more self-servicing for users, though.

williamcroberts commented 3 years ago

Is their anyway to introspect what the server is doing?

Unfortunately not in a public way. I'll make a note to the product team to make this process easier and more self-servicing for users, though.

Its hard to debug when all you get is a "it worked, it didn't work" boolean response. I also don't know why path fixups are on the server side over the client side. It would reduce work on the server and save server cycles doing that.

williamcroberts commented 3 years ago

@thomasrockhu thanks again for spending cycles looking at this:

Here is the CI side upload, I added a --dump before the upload so we could see the data:

Upload link to codecov shows "There was an error processing coverage reports":

Do you spot what the issue is? I can do a dump on the fully working one so we have a diff.

thomasrockhu commented 3 years ago

@williamcroberts I see that the coverage file uploaded to Codecov is empty which is why you probably got that error.

williamcroberts commented 3 years ago

@williamcroberts I see that the coverage file uploaded to Codecov is empty which is why you probably got that error.

Do you know why, or what to poke at, when it is empty? I don't understand why coverage is reporting above and the .coverage sqlite3 db had coverage data.