A GitHub Action that installs jolt
(native Clojure on Chez Scheme, no JVM) on a runner. There's no marketplace
action for this today, the way
DeLaGuardo/setup-clojure
covers babashka and the Clojure CLI, so this is that, for jolt.
Proof of concept. Downloads a prebuilt release from
jolt-lang/jolt's own GitHub releases and verifies its published
sha256. Every download retries up to five times, so a transient error
from GitHub's release CDN doesn't fail the job. Covers Linux x86_64 and macOS x86_64/arm64, the platforms
jolt-lang/jolt ships prebuilt binaries for today (x86_64 Windows exists
upstream too, not wired here yet).
- uses: jlt-commons/setup-jolt@v1
with:
version: '0.8.6' # or omit for "latest"
- run: jolt --version| Input | Default | Description |
|---|---|---|
version |
latest |
jolt version to install, e.g. 0.8.6. The v prefix is optional. latest resolves the newest GitHub release via the API. |
token |
${{ github.token }} |
Sent with the API call that resolves latest, which lifts GitHub's unauthenticated limit of 60 requests an hour per runner IP. Not used for a pinned version, and never sent to the release download URLs. |
| Output | Description |
|---|---|
version |
The jolt version actually installed (useful when version: latest was requested and you want to log or cache-key on the resolved value). |
lambda-mvp-jlt wanted its
docs-site CI step to run via jolt instead of installing babashka
separately, since jolt reads a project's bb.edn tasks directly. That
specific swap turned out to be blocked on the consuming side (the docs
engine's own bb.edn eagerly requires org.httpkit.server, which jolt
doesn't bundle, so its tasks don't load under jolt yet, independent of
this action), but the "how do you even get jolt onto a runner" half of
the problem was real and generally useful, so it's split out here rather
than living inline in one project's workflow.
EPL 2.0, see LICENSE.