You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our CI pipeline, some tests are run in an environment that has a git client, while others are not (integration tests that are run inside docker containers, which we don't copy the git client in). At the end, we merge coverage from both sources using cc-test-reporter sum-coverage.
When we added one large autogenerated source file to git-lfs, we started seeing a BlobID mismatch error on sum-coverage. Upon investigation, this seems to be ultimately caused by the fact that, when using git-lfs, the resulting blob id will be different depending on the presence of the git client - from my cursory read of the code, it will depend on whether fallbackGlob is used:
This is due to the fact that git-lfs rewrites files, so the hash obtained from git is not the hash of the final file.
We have worked around this by noting that code files should not be added to git-lfs, but it would be great if this was properly fixed, since it is an issue that is quite difficult to track. I suggest that the tool checks for any git smudge filters that may be set on a file, and use the fallbackGlob implementation when that happens, as this would accommodate any usage of git smudge filters (more general solution than git-lfs).
The text was updated successfully, but these errors were encountered:
In our CI pipeline, some tests are run in an environment that has a git client, while others are not (integration tests that are run inside docker containers, which we don't copy the git client in). At the end, we merge coverage from both sources using
cc-test-reporter sum-coverage
.When we added one large autogenerated source file to git-lfs, we started seeing a
BlobID mismatch
error onsum-coverage
. Upon investigation, this seems to be ultimately caused by the fact that, when using git-lfs, the resulting blob id will be different depending on the presence of the git client - from my cursory read of the code, it will depend on whetherfallbackGlob
is used:test-reporter/env/git.go
Line 133 in 22de46a
This is due to the fact that git-lfs rewrites files, so the hash obtained from git is not the hash of the final file.
We have worked around this by noting that code files should not be added to git-lfs, but it would be great if this was properly fixed, since it is an issue that is quite difficult to track. I suggest that the tool checks for any git smudge filters that may be set on a file, and use the
fallbackGlob
implementation when that happens, as this would accommodate any usage of git smudge filters (more general solution than git-lfs).The text was updated successfully, but these errors were encountered: