I made a little GitHub bot (https://github.com/j178/prek-ci-bot) and
deployed it on Vercel. It downloads CI artifacts and posts comments on
PRs. Now that it works, we can get rid of that risky `on: workflow_run`
trigger.
* feat(swift): add Swift language support
Implement Swift language support for prek:
- Query swift executable and parse version from `swift --version`
- Handle both macOS (Apple Swift) and Linux version formats
- Normalize versions without patch component (e.g., "6.1" -> "6.1.0")
- Handle pre-release versions (e.g., "6.2-dev")
- Build Package.swift repos with `swift build -c release`
- Use `swift build --show-bin-path` to resolve target-specific bin directory
- Add built binaries to PATH when running hooks
- Health check verifies swift executable still exists
Include unit tests for version parsing covering:
- macOS format with swift-driver prefix
- Linux format
- Multiline output handling
- Versions without patch component
- Development/nightly versions
- Invalid input handling
* test(swift): add Swift language tests
* docs(swift): mark Swift as supported in language documentation
* ci: stabilize swift toolchain setup across platforms
- pin Swift version in env to keep CI deterministic\n- use SwiftyLab/setup-swift on Windows where swift-actions fails\n- install Swift on macOS and reset TOOLCHAINS back to Xcode\n- force CC/CXX/SDKROOT from Xcode so Ruby native gems compile\n\nThis keeps Swift hooks available while restoring Xcode's clang/SDK,\nwhich avoids msgpack native extension failures on macOS.
* feat(bun): add Bun language support
* test(bun): add integration tests for Bun language support
Add three integration tests covering the key functionality:
- basic_bun: simple hook execution using bun -e
- additional_dependencies: verify deps installed via bunx cowsay
- language_version: test version specification with language_version: "1"
The additional_dependencies test runs twice to verify health_check and
cache reuse works correctly.
* docs: add Bun to supported languages documentation
- Add Bun to toolchain list in README features section
- Add Bun to managed toolchain downloads list in languages.md
- Add full Bun language section with version format documentation
* ci: add Bun setup to test jobs
* feat(bun): use GITHUB_TOKEN to avoid API rate limits
When listing Bun versions from GitHub releases, use the GITHUB_TOKEN
environment variable if available to authenticate requests. This
increases the rate limit from 60 to 5,000 requests/hour.
GITHUB_TOKEN is automatically set in GitHub Actions workflows.
* fix(bun): use consistent bin_dir path on all platforms
Bun installs global packages to $BUN_INSTALL/bin/ on all platforms,
so bin_dir should always return prefix/bin. The Windows special case
was incorrectly copied from Node (which uses npm's different install
structure).
* Add toolchain download test
* Add tests
---------
Co-authored-by: Jo <10510431+j178@users.noreply.github.com>
* Add Ruby support (no download support yet)
Currently only pre-existing Rubies are used, although the code will
search for and consider multiple versions. This allows a hook to require
3.4.7 when the default system Ruby is 3.4.6, but RVM (or a similar tool)
has installed 3.4.7. If a suitable Ruby cannot be found, the user is
prompted to install one manually and re-run.
Hooks get an isolated GEM_HOME, based on the hook repository, any
additional_dependencies, and the interpreter version/path. Any Ruby
upgrade would therefore re-install the gems to ensure that stale
versions aren't used. Repository gem dependencies are installed based on
the included gemspec files, combined with the additional_dependencies
field.
* Add pins for CI 'install Ruby' action
* Update setup-ruby pin
* Tweak version parsing
* Tweak env vars
---------
Co-authored-by: Jo <10510431+j178@users.noreply.github.com>
* Update GitHub Actions
* Try to speed up windows CI
* Use `leafo/gh-actions-luarocks`
* Fix luarocks install failure
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jo <10510431+j178@users.noreply.github.com>
The profiling isn’t very useful right now - it’s way too sensitive to noise. What we really need is proper benchmarking that runs multiple times to filter out all that noise, like what you get with https://codspeed.io/ or https://bencher.dev/
