cache is corrupted and truncates the packages causing build errors: T04:15:41.6017000Z with: I am running into this same issue as well. I would expect that failing to restore the cache leads to a clean build (and upload of a fixed cache).Įdit: To clarify, my cache restore error is not the same as but the outcome is the same: the cache is partially restored but the step still passes, and this partial but damaged cache is used and breaks the build step.
#Untar on windows windows
(This on the macOS running, I guess the issue is not Windows specific.)
#Untar on windows plus
Applications/Xcode_13.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: object: editor/.64.a(style_box_editor_.64.o) truncated or malformed object (LC_SEGMENT_64 command 0 fileoff field plus filesize field extends past the end of the file) There’s an unrecoverable error but the partially unarchived cache is still used, and the build fails due to a truncated file, which in turns makes all PR builds fail similarly.
#Untar on windows code
Warning: Tar failed with error: The process '/usr/local/bin/gtar' failed with exit code 2 usr/local/bin/gtar: Error is not recoverable: exiting now
#Untar on windows archive
usr/local/bin/gtar: Unexpected EOF in archive *stdin*\ : Decoding error (36) : Corrupted block detected usr/local/bin/gtar -use-compress-program zstd -d -xf /Users/runner/work/_temp/6a55a559-2ae9-4bd4-b526-8f0ac001b803/cache.tzst -P -C /Users/runner/work/godot/godot -delay-directory-restore I confirm that I’m running into a similar issue today: Received 88080384 of 990229141 (8.9%), 83.9 MBs/sec # the previous job, there is a low chance that it'll have been evicted by # Build LLVM if we didn't hit in the cache. Here’s the relevant excerpt of the workflow: # Try to fetch LLVM from the cache. This second option would be tricky since in this case it’s overwriting the source files and adding the build outputs. Alternatively, don’t fail, don’t set cache-hit, but clean up the (partially) restored files. The intuitive behavior in case of this error is to fail in the cache step. (This is a new workflow which I’m still debugging.)Īs a result of this warning, the cache-hit output variable isn’t being set but the cache has been at least partially restored, resulting in an error in the rebuild step. This part of the workflow works when we don’t hit in the cache.
I don’t know what’s special about this file. Tar.exe: Error exit delayed from previous errors. We’re hitting an issue when untar’ing a cached LLVM build on Windows: llvm/lld/test/ELF/Inputs/aarch64-copy2.s: Refusing to overwrite archive
0 kommentar(er)
