ci: run the action where the README says it runs - #52
Merged
Merged
Conversation
The composite action is about to be listed on the Marketplace and its README offers it to Linux, macOS and Windows runners. Only Linux had ever run it: the pre-commit job uses `./`, and nothing else did. The macOS and Windows halves of the install script -- `shasum` where there is no `sha256sum`, `7z` and the `.zip` archive, the Darwin and Windows archive names -- shipped unexecuted, which is a poor thing to discover from a stranger's bug report on launch day. There was already one defect down that path. action.yml maps RUNNER_ARCH=ARM64 to `pre-commit_Windows_arm64.zip`, and that archive does not exist: .goreleaser.yaml ignored goos=windows/goarch=arm64. On a windows-11-arm runner the action would have 404ed on the download. Nothing required the exclusion -- windows/arm64 cross-compiles clean, verified against every published target -- so the ignore is gone and the README's "Windows (amd64/arm64)" becomes true with the next release rather than being an overclaim. The new job asserts more than an exit code, because installing nothing and running nothing also exits 0: the binary must answer to the name `pre-commit` on PATH, and a real hook must build its environment, run, and leave the file changed on disk. Linux is deliberately not in the matrix. The pre-commit job already runs the action on ubuntu-latest for every commit, so a third runner here would buy no coverage. windows-11-arm is not in the matrix yet either: the action installs the *released* binary, and no release contains a Windows arm64 archive until one ships with the .goreleaser.yaml change above. It can be added once that release exists. Refs #43
The first run of this job did its job immediately: macOS passed and
Windows failed, with
failed to install environment for hook "trailing-whitespace":
pip install failed: exec: "...\py_env-default\bin\pip":
executable file not found in %PATH%
Every language backend that installs an environment hardcodes a `bin`
directory. A Windows virtualenv puts its executables in `Scripts`, and
`Scripts` appears nowhere in this repo -- runtime.GOOS is consulted only
in docker.go. So python, node, ruby and golang hooks are all broken on
Windows, not merely unexercised.
That is too large to fold into a launch change, so this commit stops
claiming otherwise. The docs said "Windows has never been exercised by
anyone; it builds, and that is the extent of what is known", which reads
as "probably fine". It is not fine, and a reader deciding whether to
adopt this deserves the specific version: the binary installs and runs,
`pygrep`, `fail`, `system` and `script` hooks work, and anything that
builds an environment does not.
The job now asserts exactly that split rather than leaving a permanent
red X on Windows that everyone learns to ignore: the environment-free
hook runs on both platforms, and the python hook runs on macOS. The
Windows leg is a real guard for the part that works -- the action's
download, checksum, extraction and PATH handling, which do work there.
Refs #43
A limitation with no tracking number reads as permanent.
blairham
force-pushed
the
action-cross-os
branch
from
September 8, 2026 01:34
c5a6529 to
56d684b
Compare
16 of 19 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the launch-readiness pass for #43, and a prerequisite for listing the action on the Marketplace.
The gap
The action's README offers it to Linux, macOS and Windows. Only Linux had ever run it — the
pre-commitjob uses./, and nothing else did. The macOS and Windows halves of the install script shipped unexecuted:shasum -a 256on macOS, where there is nosha256sum7zand the.ziparchive on WindowsDarwin_*andWindows_*archive names$GITHUB_PATHandpre-commit --versionresolving to.exeunder git-bashA defect was already sitting there
action.ymlmapsRUNNER_ARCH=ARM64→pre-commit_Windows_arm64.zip. That archive does not exist —.goreleaser.yamlignoredgoos: windows / goarch: arm64:So on a
windows-11-armrunner the action would 404 on the download. Nothing required the exclusion — windows/arm64 cross-compiles clean:$ CGO_ENABLED=0 GOOS=windows GOARCH=arm64 go build -o /dev/null . # OK(verified across all ten published targets). The ignore is removed, which also makes the README's "Windows (amd64/arm64)" true with the next release instead of an overclaim.
What the job asserts
Installing nothing and running nothing also exits 0, so exit codes alone would not be evidence. The job requires:
pre-commitresolves on PATH by that name — the drop-in contractScope
The action installs the released binary, so this tests the install path and the current release, not the code in the PR. That is intended — "does the thing we publish work where we say it does".
windows-11-armis not in the matrix yet: no release contains a Windows arm64 archive until one ships with the.goreleaser.yamlchange here. It can be added right after.Refs #43