fix: ensure tar supports Zstd

[JackMyers001]

Summary

• Updates decision for downloading Zstd archive to check that the version of tar installed supports Zstd

Root Cause

As noted in #568, the action previously selected a Zstd-compressed archive after checking only zstd --version, but extracts the archive with tar --zstd. This fails on RHEL 8-compatible runners that ship zstd 1.4.4 and GNU tar 1.30, which does not recognize the --zstd option.

Fixes #568.

Validation

• Underlying problem (missing --zstd flag confirmed within a RHEL 8 VM + almalinux:8 container
  • Confirmed zstd --version exits successfully
  • Confirmed tar --zstd --version exits with an unrecognized-option error in this environment, but works with newer tar versions (checked with 1.35, but should be available from ~1.31)
• Run on a real RHEL8 self-hosted Runner that fails without this patch

I was unable to run mise run test or the pre-commit hook due to npm install failing; all passed after downgrading TypeScript to v6 (this appears to be unrelated to my change).

Summary by CodeRabbit

• Bug Fixes
  • Improved archive selection to verify full .tar.zst support before use.
  • Automatically falls back to .tar.gz archives when the system’s tar command cannot handle Zstandard compression.

[coderabbitai]

📝 Walkthrough

Walkthrough

setupMise now selects .tar.zst archives only when both zstd and tar’s --zstd flag are available; otherwise it uses .tar.gz.

Changes

Archive capability selection

Layer / File(s)	Summary
Tar zstd capability check src/index.ts	Replaces zstdInstalled() with tarSupportsZstd(), checking both zstd --version and tar --zstd --version before selecting the .tar.zst archive.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: jdx, jdx

Poem

I’m a bunny checking tar,
“Can you zstd?” near and far.
Both commands must agree,
Then the right archive hops to thee.
Carrots cheer the safer choice! 🐇

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: validating that tar supports Zstd before choosing the Zstd archive.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

Tightens Zstandard archive selection so the action uses .tar.zst only when both zstd and tar --zstd are available.

• Renames the capability check from zstdInstalled to tarSupportsZstd.
• Adds a tar --zstd --version probe and retains gzip as the fallback.
• Regenerates the bundled action and source map.

Confidence Score: 5/5

The PR appears safe to merge, with the runtime bundle consistently implementing the intended Zstandard capability check.

The new probe rejects runners lacking either the Zstandard executable or tar --zstd support and selects the existing gzip path instead; the checked-in runtime bundle matches the source implementation.

Important Files Changed

Filename	Overview
src/index.ts	The archive selection now verifies the same tar --zstd capability used during extraction, with a safe gzip fallback.
dist/index.js	The executable action bundle faithfully includes the updated capability probe and call site.
dist/index.js.map	The generated source map was updated alongside the bundled action.

_{Reviews (1): Last reviewed commit: "fix: ensure `tar` supports Zstd" | Re-trigger Greptile}