sway Public

Watch 0 Fork 0 Star 0
markdown · 2781 bytes Raw Blame History

Pre-commit gate example

A copy-paste recipe for plugging sway gate into any repo's git commit flow via pre-commit.com.

What this gives you

On every git commit that touches sway.yaml, a .dlm document, or an adapter/ directory, pre-commit runs sway gate against your spec. A FAIL verdict aborts the commit with the terminal banner you'd see from sway gate directly. No more "oops, I broke the adapter and didn't notice until the next manual sway run."

Which variant

sway ships two hooks. Pick whichever matches your install posture:

Hook When to use Cost
sway-gate sway is already on your PATH (pip install 'dlm-sway[hf]') Milliseconds of hook overhead + the actual gate runtime
sway-gate-isolated fresh venv, no existing sway install First run installs sway + torch + transformers (~5 GB, ~2 min). Subsequent runs reuse the cached venv.

This example shows sway-gate as the default and sway-gate-isolated commented out. Swap them in .pre-commit-config.yaml if you want the isolated variant.

Setup (4 steps)

  1. Install pre-commit: pipx install pre-commit (or pip install pre-commit if you don't use pipx).
  2. Copy this directory's .pre-commit-config.yaml into your repo root. If you already have one, merge the - repo: block.
  3. Edit sway.yaml in your repo to point at your real base model and adapter paths.
  4. Install the hook: pre-commit install.

That's it. The next git commit that matches the hook's file filter will run sway gate before the commit finalizes.

Rev pinning

The example's .pre-commit-config.yaml pins to a specific commit SHA because sway hasn't tagged a v0.1.0 release yet. Pinning to HEAD would silently drift your gate's behavior on every pre-commit autoupdate; pinning to a SHA is the honest pre-release pattern.

Bump the SHA deliberately when you want to pick up new probes or bug fixes. After sway publishes v0.1.0 you'll switch to rev: v0.1.0 and forget about SHAs.

Scope discipline

The hook only gates — exits non-zero on FAIL, zero on PASS. It does not emit JSON / markdown reports; those are for sway run (called ad-hoc or in a separate CI job). Keeping the hook focused means git commit stays fast and the gate's verdict stays the headline signal.

Trying it locally before committing

If you want to see the hook fire before integrating it into a real repo:

# From your repo's root, after copying the config in and editing
# the spec paths:
pre-commit run sway-gate --all-files

That runs the hook against every tracked file and surfaces the full terminal report. A subsequent git commit will run the hook only against staged files — same logic, narrower scope.

View source
1 # Pre-commit gate example
2
3 A copy-paste recipe for plugging `sway gate` into any repo's `git
4 commit` flow via [pre-commit.com](https://pre-commit.com).
5
6 ## What this gives you
7
8 On every `git commit` that touches `sway.yaml`, a `.dlm` document, or
9 an `adapter/` directory, pre-commit runs `sway gate` against your
10 spec. A FAIL verdict aborts the commit with the terminal banner
11 you'd see from `sway gate` directly. No more "oops, I broke the
12 adapter and didn't notice until the next manual `sway run`."
13
14 ## Which variant
15
16 sway ships two hooks. Pick whichever matches your install posture:
17
18 | Hook | When to use | Cost |
19 |---|---|---|
20 | `sway-gate` | sway is already on your `PATH` (`pip install 'dlm-sway[hf]'`) | Milliseconds of hook overhead + the actual gate runtime |
21 | `sway-gate-isolated` | fresh venv, no existing sway install | First run installs sway + torch + transformers (~5 GB, ~2 min). Subsequent runs reuse the cached venv. |
22
23 This example shows `sway-gate` as the default and `sway-gate-isolated`
24 commented out. Swap them in `.pre-commit-config.yaml` if you want the
25 isolated variant.
26
27 ## Setup (4 steps)
28
29 1. Install pre-commit: `pipx install pre-commit` (or `pip install
30 pre-commit` if you don't use pipx).
31 2. Copy this directory's `.pre-commit-config.yaml` into your repo
32 root. If you already have one, merge the `- repo:` block.
33 3. Edit `sway.yaml` in your repo to point at your real base model
34 and adapter paths.
35 4. Install the hook: `pre-commit install`.
36
37 That's it. The next `git commit` that matches the hook's file filter
38 will run `sway gate` before the commit finalizes.
39
40 ## Rev pinning
41
42 The example's `.pre-commit-config.yaml` pins to a specific commit
43 SHA because sway hasn't tagged a v0.1.0 release yet. Pinning to
44 `HEAD` would silently drift your gate's behavior on every `pre-commit
45 autoupdate`; pinning to a SHA is the honest pre-release pattern.
46
47 Bump the SHA deliberately when you want to pick up new probes or
48 bug fixes. After sway publishes v0.1.0 you'll switch to
49 `rev: v0.1.0` and forget about SHAs.
50
51 ## Scope discipline
52
53 The hook **only gates** — exits non-zero on FAIL, zero on PASS. It
54 does not emit JSON / markdown reports; those are for `sway run`
55 (called ad-hoc or in a separate CI job). Keeping the hook focused
56 means `git commit` stays fast and the gate's verdict stays the
57 headline signal.
58
59 ## Trying it locally before committing
60
61 If you want to see the hook fire before integrating it into a real
62 repo:
63
64 ```bash
65 # From your repo's root, after copying the config in and editing
66 # the spec paths:
67 pre-commit run sway-gate --all-files
68 ```
69
70 That runs the hook against every tracked file and surfaces the
71 full terminal report. A subsequent `git commit` will run the hook
72 only against staged files — same logic, narrower scope.