feat(setup-pack): add pack-version-file input and verify download checksum

[somaz94]

The setup-pack action only accepted an explicit pack-version, and it piped the downloaded archive straight into tar with no integrity check. This adds two things:

1. A pack-version-file input that reads the version from a .tool-versions file (the pack entry) or a plain version file like .pack-version. Version resolution is now pack-version → pack-version-file → a pinned default, so an explicit pack-version always wins even when pack-version-file is also set — matching the setup-go go-version / go-version-file convention.
2. Default-on SHA256 verification. Each pack release publishes a sibling <asset>.sha256, so the action now downloads the archive to a temp file, verifies it against that checksum, and only then extracts. If the checksum cannot be fetched it warns and proceeds, so mirror / air-gapped setups are not broken.

⚠️ Breaking change (major version bump)

To make the precedence above work, the pack-version input default was removed. setup-go can treat an empty go-version as "unset", but pack-version always carried a default, so a composite action could not tell "user asked for the default" from "defaulted" — which made pack-version-file unreachable whenever a default was present. The default is now a DEFAULT_PACK_VERSION in the step env: block, used only when neither input is set, and the update-pack-version workflow's sed is re-pointed at that line so the auto-bump keeps working.

Runtime behavior is unchanged for existing users (with nothing set, the pinned default is unchanged). But removing the input default is an API change, so this should land as a major version bump.

Validation

Done locally (the repo has no composite-action test harness, only the Go unit tests):

• Version resolution covered: precedence (both set → inline wins / file-only / neither → default), .tool-versions with a pack entry (tab separated + trailing comment), plain version file (leading v, blank/comment lines, and inline trailing comment like 0.40.6 # pinned), and missing-file error.
• Checksum path verified end to end against a real linux asset: a matching sum passes, a corrupted archive is rejected, and tar member extraction still yields the pack binary.
• Re-pointed update-pack-version sed re-verified against the new DEFAULT_PACK_VERSION: env line.
• shellcheck clean on both inline scripts.

[dmikusa]

This sounds great! A couple of notes/questions:

1. Question about precedence of the operators:

When set it takes precedence over pack-version.

This sounds backwards to me. As I read this, my understanding is that pack-version-file would take precedent over pack-version. Typically, the inline version takes precedent so pack-version would override pack-version-file. As an example, see the setup-go action docs:

If both the go-version and the go-version-file inputs are provided then the go-version input is used.

https://github.com/actions/setup-go/blob/main/docs/advanced-usage.md#using-the-go-version-file-input

2. Question about sha256 checksum validation. I gather that you've added this for the pack-version-file case, did you also add sha256 validation for the pack-version path? As a user, I'd expect both paths to work the same way.

[somaz94]

Thanks for the review!

On the checksum (2): it already covers both paths. The download and sha256 verification are in the shared "Install pack CLI" step that runs after version resolution, so the same archive is fetched and checked the same way whether the version came from pack-version or pack-version-file.

On precedence (1): you're right that inline-wins is the usual convention. I had the file win because pack-version carries a default (0.40.6, kept current by the update-pack-version workflow's sed on the default: line). Unlike setup-go's go-version, pack-version is never empty, so a composite action can't distinguish "user set 0.40.6" from "defaulted", and inline-always-wins would make pack-version-file unreachable.

If you're open to it I can match setup-go: drop the input default, resolve pack-version then pack-version-file then a fallback baked into the resolve step, and point the update-pack-version sed at that fallback line so the auto-bump still works. Or I keep file-as-override and just document it. Which do you prefer?

[jjbustamante]

@somaz94 , @dmikusa . @edmorley

The checksum validation in this PR is valuable and backward-compatible on its own, so I'd suggest we land it and handle the pack-version vs pack-version-file precedence question as a follow-up? For reference, here's the trade-off we'd revisit:

Scenario	PR as-is (file wins)	setup-go semantics (inline wins)
User sets nothing	default 0.40.6	needs a fallback baked into the resolve step
User sets pack-version only	that version	that version
User sets pack-version-file only	file version	file version
User sets both	file wins (non-standard)	inline wins (standard)
update-pack-version auto-bump	keeps working (default line untouched)	breaks unless the sed is re-pointed
Convention match	surprising	familiar

Based on that, I agree with @somaz94 approach to drop the default and add the fallback but we need to be careful with the automation for update-pack-version we have in place right now.

[somaz94]

Thanks both. I went with the inline-wins redesign you endorsed rather than splitting, since it's contained to this PR:

• Dropped the pack-version input default and added a FALLBACK_PACK_VERSION constant in the resolve step. Precedence is now pack-version → pack-version-file → fallback, so an explicit pack-version wins even when pack-version-file is set — matching setup-go's go-version / go-version-file rule (@dmikusa's point 1).
• Re-pointed the update-pack-version workflow's sed from the old default: line to the new FALLBACK_PACK_VERSION='…' line, so the auto-bump keeps working (@jjbustamante's automation concern). Verified the regex still matches and rewrites the fallback line.
• On @dmikusa's point 2: checksum verification already covers both paths — it runs in the shared "Install pack CLI" step after version resolution, so it applies regardless of which input set the version.

Behavior stays backward compatible: with nothing set, the fallback equals the previous default. Validated locally — precedence (both / file-only / neither / leading-v / missing-file) and the re-pointed sed, plus shellcheck clean. Happy to split checksum out instead if you'd still prefer that.

[edmorley]

Thank you for the PR! Couple of comments but other than that looks good to go :-)

[edmorley]

Could you also rebase on main to resolve the merge conflicts?

[somaz94]

Rebased onto main (the conflict was the update-pack-version auto-bump of the old default, now folded into FALLBACK_PACK_VERSION) and addressed all three review comments:

• Parser inline-comment bug — plain version files now strip a trailing # ... comment before whitespace removal, so 0.40.6 # pinned resolves correctly.
• Fallback location — moved into the step env: block as FALLBACK_PACK_VERSION, with the update-pack-version sed re-pointed accordingly.
• PR description — updated to flag the default removal as a breaking change / major version bump.

shellcheck clean and version resolution re-validated locally. Thanks for the review!

[somaz94]

Done — I've rebased onto the latest main and force-pushed. GitHub now shows the PR as mergeable with no conflicts. Thanks!

[edmorley]

Thank you for the changes!

A few unrelated changes snuck in since the last review (LLM?) - left some comments on those to revert in some cases (eg the "default" -> "fallback" change)

[somaz94]

Thanks @edmorley — all six review comments are addressed in the pushed commits: inline trailing-comment stripping in the plain-file parser (0.40.6 # pinned no longer breaks the URL), the "could not determine a pack version" guard is now reachable, fallback reverted to default throughout, the fallback version moved into the step env: block, the PR description now calls out the breaking change / major bump, and the design-rationale prose is dropped from the input docs + README. PTAL / ready to resolve when you are.

[somaz94]

Rebased on main 👍 The earlier conflicts are gone — the only change on main since was the Go modules bump (#433), which doesn't touch the setup-pack action files, so it merges cleanly now.

The unrelated changes you flagged were all reverted in the earlier round:

• fallback → default throughout (variable, comment, and the strings in update-pack-version.yml)
• dropped the design-rationale prose from the input docs / README

Ready for another look whenever you have a moment — thanks!

[edmorley]

Thank you for the PR! (And sorry for the delay in reviewing)

[edmorley]

Released in v6.0.0:
https://github.com/buildpacks/github-actions/releases/tag/v6.0.0

[edmorley]

Example of the new version working in CI (using the pinned default version):
https://github.com/heroku/buildpacks-python/actions/runs/29577246462/job/87874412638?pr=596#step:8:128