Open LebedevRI opened 11 months ago
Hi @LebedevRI ,
This does look like a path fix issue, from looking at the logs. As an example, we are trying to match
D:/a/rawspeed/rawspeed/rawspeed/bench/librawspeed/bench/Common.cpp
in the coverage report
to
bench/librawspeed/bench/Common.cpp
in the file tree.
Which, I would expect to work.
Can you share a working example report as well so I can compare?
I don't have an example of an successful upload originating from windows. I'm not really sure if it ever worked, thought i think it did a long time ago.
You can see the uploads originating from linux/macOS here: https://app.codecov.io/gh/darktable-org/rawspeed/commit/ef4e7a458dfd22b8dc85ea7a57bbee394e824fd6
namely:
Thank you!
That's what I meant, yah. Sorry for not being clear.
I think it has to be the drive letter. Can you adding a path fix rule of D\:/:/
and see what happens? I'm actually not sure what and how things should be escaped, but I hope that's correct.
Hmm. Neither
fixes:
- "(D:/)::"
https://app.codecov.io/gh/darktable-org/rawspeed/commit/05a02ac7fbbd5cd6209a108ba36abe04745e5cd8
nor
fixes:
- "D:/a/rawspeed/rawspeed/rawspeed::"
https://app.codecov.io/gh/darktable-org/rawspeed/commit/bb489973f2802c9d69dfcacbe654bf9fa45ced1f
seems to do the trick. It's possible i do not understand what the expected syntax of fixes
is.
Thanks!
The syntax is <before>:<after>
So in the example I suggested, the goal would be to turn D:/
into /
The colon would cause a problem with the match divider, which is why I was attempting to escape it.
Hm, but https://docs.codecov.com/docs/fixing-paths says ::
, not :
, and if i use :
, the yml
does not validate.
Also, that page says that the drive letter is already taken care of:
"(\w\:\/)"
E:/ C:/
I've tried a few more patterns, but i'm failing to find the right incantation, especially given that there is no way to know how the paths look after the fixes applied, nor what the actual problem is...
Edit: Apparently I logged into the wrong account. This is @drazisil-codecov
Hm, but https://docs.codecov.com/docs/fixing-paths says
::
, not:
, and if i use:
, theyml
does not validate.
Right, sorry. 🤦♀️
Also, that page says that the drive letter is already taken care of:
"(\w\:\/)" E:/ C:/
Clearly I need to make sure the caffeine kicks in before I try to think. :-/
I've tried a few more patterns, but i'm failing to find the right incantation, especially given that there is no way to know how the paths look after the fixes applied, nor what the actual problem is...
Well, I can tell you from the logs that you are hitting https://github.com/codecov/worker/blob/8e60c869ceed319e78f1082418f245f798592224/services/report/__init__.py#L829
However, outside of "probably path fixes", I'm having a very hard time tracking down what the problem is. I appreciate your patience. 🤔
This is what happens when you have too many accounts for testing. 🤦♀️
Going to need to defer to @thomasrockhu-codecov for this one.
@ LebedevRI apologies, I just saw this issue, but it has been almost half a year. Do you mind updating me on whether this is still an issue, and if so, what is the core problem here?
Do you mind updating me on whether this is still an issue,
https://app.codecov.io/gh/darktable-org/rawspeed/commit/3d7f175657db80030fe8884ae196051034de3870 (which is the newest commit to the repo) still says
Uploads 5 successful, 2 errored
So it appears to be still happening.
and if so, what is the core problem here?
I don't have a clue :) As far as i'm aware the issue is on your side.
Downloading those reports that are unusable report
,
and manually looking through them / comparing them to the reports from other OS'es,
does not show any particular differences.
For example consider this job: https://github.com/darktable-org/rawspeed/actions/runs/6973716701/job/18978194021#step:8:1 ... which produced https://app.codecov.io/gh/darktable-org/rawspeed/commit/6e0d1e8d6fffcb6b0af787b6f7ad6bd99c1bb6b2
windows-latest.MINGW64.GNU.Coverage.Unittests
upload: https://api.codecov.io/upload/gh/darktable-org/rawspeed/download?path=v4/raw/2023-11-23/9596CAB5DCB2366A84ECB7476E65EB08/6e0d1e8d6fffcb6b0af787b6f7ad6bd99c1bb6b2/da426591-14ba-4802-b46f-9dc94acba5ff.txt ... which is very much not empty, yet is reported asunusable report
. Example content:This works for reports coming from linux and macos, example content:
I'm not sure why the empty newline is missing after
EOF
. Are default path fixes not sufficient to handle these paths? I'm not quite sure what is wrong.Thanks!