Cache: Preserve exact timestamps

[OlegYch]

Some tools (like https://www.scala-sbt.org/) rely on files timestamps with millisecond precision.
Currently cache preserves timestamps only down to second precision.
The fix would be to simply use posix format when tarring files.
https://github.com/actions/cache/pull/233 was my attempt at fixing it but it no longer works with current master

[jcayzac]

I really need this too! xcodebuild depends on timestamps.
@OlegYch meanwhile, please do not delete your posix branch as my workflow depends on it :)

[jcayzac]

Actually, after spending two days trying to get incremental builds to work, I just remembered git doesn't support timestamps and I gave up.

[jcayzac]

I guess I need an action that takes the timestamp of the base ref, applies it to all files, then takes the timestamp of the head ref and applies it to all modified/added files.

[jcayzac]

I guess I need an action that takes the timestamp of the base ref, applies it to all files, then takes the timestamp of the head ref and applies it to all modified/added files.

I ended up using chetan/git-restore-mtime-action for that.

Example steps:

- name: 'Restore timestamps'
  uses: chetan/[email protected]

- name: 'Cache: Derived data'
  uses: OlegYch/cache@posix
  id: cache-derived-data
  with:
    path: .build/derived-data
    key: ${{ runner.os }}-deriveddata-${{ github.base_ref }}@${{ github.event.pull_request.base.sha }}-${{ github.head_ref }}@${{ github.sha }}
    restore-keys: |
      ${{ runner.os }}-deriveddata-${{ github.base_ref }}@${{ github.event.pull_request.base.sha }}-${{ github.head_ref }}@
      ${{ runner.os }}-deriveddata-${{ github.base_ref }}@${{ github.event.pull_request.base.sha }}-
      ${{ runner.os }}-deriveddata-${{ github.base_ref }}@

[OlegYch]

@jcayzac posix branch does not work as it's based on broken master, posixv1 works, i'm going to keep it until this is fixed in upstream

[jcayzac]

For reference, here's the commit https://github.com/OlegYch/cache/commit/a39be91a23ff474b988f47a25b952db79045befa

[OlegYch]

@jcayzac yep that one works

[smorimoto]

I've opened a PR about this. Hopefully, we can include this in the first release of v2.

[OlegYch]

cheers

[smorimoto]

Upstream code has been fixed. I just opened a PR to downstream to apply it, and it will be merged soon if things go well. FYI: @OlegYch @jcayzac @JosephDuffy

[konradpabjan]

Reopening, this issue automatically closed itself after the pr in toolkit went in. Need to update the package version here and create a new create.

[smorimoto]

@aiqiaoy Now we can close this issue.