Open mzabaluev opened 4 years ago
Also consider using a .gitattributes file to control the line endings on windows
Also consider using a .gitattributes file to control the line endings on windows
I'm not sure cargo would honor it when writing an updated lock file. More generally, forcing Unix-style endings on a file would inconvenience many developers just so a CI workflow can run correctly, which I think is not a good tradeoff.
For it to be a problem in CI, developers in different OSes would need to be committing lock file changes (and other files) with different line endings. That seems like it could be problematic outside of CI. I don't think you also need to force unix style endings - you just need consistency which seems like a good practice as other tools will have issues (which is why git has options).
... however, I do agree that having an option that was line ending agnostic (filters out line endings to generate the contents to create the hash) would be a good enhancement
For it to be a problem in CI, developers in different OSes would need to be committing lock file changes (and other files) with different line endings.
Not only that: it's common to check in the package-lock.json
or the Cargo.lock
for an application project to ensure reproducible builds, even though these files are managed by the build tools. Git checks out text files with the OS line ending format unless overridden, and it's good in general, because developers may also want to view these files or use some other tools on them, which might be problematic on Windows with the non-conformant line endings (though there are fewer tools that don't work with either format these days).
A real-world use case for this is caching a local Maven repository, calculating the cache key from ${{ hashFiles('**/pom.xml') }}
, which is a frequent use case in many projects. This yields one set of cache files for Linux and MacOS, but another one one Windows. As was discussed above, using .gitattributes
and influence all users just so as to fix caching on CI is not an adequate solution, way too invasive.
See also:
Describe the enhancement Sometimes cached data is sufficiently cross-platform to be reused across runners on Windows and the Unix OSes. A problem arises if the cache key needs to be computed by hash-summing text files, which produces differing hash sums on the same file if it was e.g. checked out by git in text mode applying auto-conversion to the line endings.
This workflow run failed to hit the cache in the Windows
test
job, even though the precedingupdate-deps
job on Linux had stored it.Code Snippet It would be nice if a
hashTextFiles
function was available that would canonicalize line endings for the hash input: