Hotfix Zstd breaking due to version change in runners#1353
Conversation
…rking. Defaulting to zstd without long as that is what is always happening currently.
976c8e8 to
853e85a
Compare
853e85a to
0f91c9c
Compare
|
Checks are failing. Please fix the unit tests. |
8708d41 to
e6e2984
Compare
| core.debug(`Checking ${app} ${additionalArgs.join(' ')}`) | ||
| try { | ||
| await exec.exec(`${app} --version`, [], { | ||
| await exec.exec(`${app}`, additionalArgs, { |
There was a problem hiding this comment.
Thanks again @pdotl!
Just saw this while looking at the PR. '${app}' seems a bit redundant. The first argument should be a string and app is already one. Maybe you can fix that when you address the zstd --long issue. It would be a bit much to open a separate PR for it 😅
There was a problem hiding this comment.
Sure @cdce8p will take this up in the next PR.
Phantsure
left a comment
There was a problem hiding this comment.
Looks fine to remove --long check entirely. --quiet would supress warnings but not clear how that would help in semver readable text
Found this in the documentation for
|
Summary
Currently zstd check is dependent on the text output of the
zstd --versionto includezstd command line interface. This text changed to*** Zstandard CLI (64-bit) v1.5.4, by Yann Collet ***breaking the check and@actions/cachealways falling back togzipcompression.Implementation
gzipif the version output string is empty which should be the case if zstd is not installed.--quietflag tozstdso moving on thezstd --versionshould output machine readable version parsable via SemVer instead of text.--longas that is what currently happens.Next Steps
Will have another PR that fixes use of
zstdwith--longas intended. This release should unblockzstdusage.Issues
Fixes #1341