Open rashboldb opened 1 week ago
It definitely relates somehow to git LFS. I've added files to fit lfs that were previously simply committed.
After I've updated my .gitattributes
file, and then did git add --renormalize .
and pushed the commit - then it got broken. If I revert the commit which does this it all works good again.
Hm, it appears that whatever you did triggered a new line to appear in git diff
that the action doesn't know how to parse. This is a consequence of git not really providing an easily-parseable output. Can you figure out what the diff contains ? Then we should be able to 1/ fix this, 2/ make the code more robust, 3/ display the diff in case we fail parsing it.
(PRs welcome if you have the time)
@ewjoachim the line it fails on starts with @@����x]o�(:�
(it's a part of the binary file, PDF to be explicit). Changing the condition in parse_diff_output
from if line.startswith("@@")
to if line.startswith("@@ ")
(adding a space) will fix the issue in this particular case, but idk how reliable the approach is:)
I thought git didn't display the diff of binary files. I wonder what makes it decide to do so.
Let's fix this the way you mentioned.
wait... How does the line start with @@ without being a @@
diff line ? The assumption is that the lines that contain user-dependent files start with +
or -
or
?
@ewjoachim, idk. mb the problem is that splitlines()
doesn't work well with it.
This is the first time the issues happed, idk what to do. The workflow has no issues running on the other branches, but constantly fails in one specific PR.
any ideas?