A line ending invariant alternative to hashFiles

[mzabaluev]

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 preceding update-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:

  test:
    needs: update-deps
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - id: cargo-registry
        name: Restore cargo registry
        uses: actions/cache@v1
        with:
          path: ~/.cargo/registry
          key: cargo-registry-${{ hashTextFiles('**/Cargo.lock') }}

[ericsciple]

Also consider using a .gitattributes file to control the line endings on windows

[mzabaluev]

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.

[bryanmacfarlane]

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).

[bryanmacfarlane]

... 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

[mzabaluev]

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).

[kriegaex]

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:

• https://github.com/actions/cache/issues/614
• https://github.com/actions/checkout/issues/135